He aquí el último video de este par de orates. Algo que me llama la atención es que se clavaron con PHP y dejaron de lado Java ¿la razón? La ignoro. ¿Será acaso que los PHP'eros tienen menos elementos para defenderse?
Cada vez que alguien conoce Rails se entusiasma de manera increíble. Es que Rails realmente es increíble. Te deja con una sensación de productividad como si te hubieras metido no sé que cosa. Desarrollas rápido, no importan los cambios, el 90% de las veces los consigues cambiando archivos de configuración, te concentras en otorgar valor en el marco del negocio y no en el de la tecnología.
Sin embargo, casos como Twitter demuestran que no todo es miel sobre hojuelas. Menciono Twitter por que es el caso más conocido y que además uso regularmente :D. Además de la serie de posts del mismo DHH y el equipo Twitter, las extensiones a estos posts (tipo programa de notas faranduleras) en las que ponen a DHH como un ególatra energúmeno sabelotodo que lo único que hace es regañar a los desarrolladores de Twitter.
Sea cual fuere la razón Rails en Twitter fue y es rebasado. Y si miran el modelo, es terriblemente simple. ¿Significa esto que Rails no vale la pena? ¿Qué no tiene el solicitado status de nivel empresarial? Para mí significa que igual que con cualquier tecnología, la solución está de nuestro lado: desarrolladores, arquitectos, hw-junkies y demás. No hubo, no hay ni habrá tecnología que llegué a sustituir al 100% las capacidades humanas. Cuando menos no durante lo que yo viva.
Entonces, no importa que Twitter falle. Agarren Rails y cójanle cariño. Vayan probando hasta donde pueden estirar la liga de la suerte. Estirenla tan fuerte que se rompa y entonces aflojen un poquito. Esa será la medida correcta (¡Gracias Jeff!).
Después de este choro viene la diversión.
Finito.
viernes, mayo 25, 2007
jueves, mayo 24, 2007
La culpa no la tiene el servicio sino el que lo hace Web Service
Hace un par de días hubo una acalorada discusión en relación a un proceso de integración entre dos sistemas: el expediente clínico electónico (ECE) y el sistema que se encarga de administrar a los usuarios de los diversos servicios de centros deportivos y sociales.
Resulta que los web services que expone ECE se definen en el correspondiente WSDL de la sigte manera:
<s:element name="CargaReferencia">
<s:complextype>
<s:sequence>
<s:element minoccurs="0" maxoccurs="1" name="docHL7Referencia">
<s:complextype mixed="true">
<s:sequence>
<s:any/>
</s:sequence>
</s:complextype>
</s:element>
</s:sequence>
</s:complextype>
</s:element>
Y del otro lado se tiene
<s:element name="procesaOci">
<s:complexType>
<s:sequence>
<s:any/>
</s:sequence>
</s:complexType>
</s:element>
Es decir. Técnicamente reciben cualquier cosa (<s:any/>).
Hace un poco más de un año, se realizó una junta para evaluar una propuesta de arquitectura para los servicios del ECE. Lo curioso es que pasado el tiempo siguen en las mismas.
¿pa'qué definir un contrato? Le pasamos cualquier cosa. ¿pa'qué validar contra un esquema? La validación la hacemos con un flujo o mejor aún: tirando código (que se factura por hora). No tiene ningún caso desacoplar, incluso cuando existen appliances para validar esquemas.
El chiste del outsourcing es quemar horas reinventando el hilo negro, divagando en arquitecturas y pelearse entre sí.
En fin, la culpa no la tiene el servicio.
Finito.
Resulta que los web services que expone ECE se definen en el correspondiente WSDL de la sigte manera:
<s:element name="CargaReferencia">
<s:complextype>
<s:sequence>
<s:element minoccurs="0" maxoccurs="1" name="docHL7Referencia">
<s:complextype mixed="true">
<s:sequence>
<s:any/>
</s:sequence>
</s:complextype>
</s:element>
</s:sequence>
</s:complextype>
</s:element>
Y del otro lado se tiene
<s:element name="procesaOci">
<s:complexType>
<s:sequence>
<s:any/>
</s:sequence>
</s:complexType>
</s:element>
Es decir. Técnicamente reciben cualquier cosa (<s:any/>).
Hace un poco más de un año, se realizó una junta para evaluar una propuesta de arquitectura para los servicios del ECE. Lo curioso es que pasado el tiempo siguen en las mismas.
¿pa'qué definir un contrato? Le pasamos cualquier cosa. ¿pa'qué validar contra un esquema? La validación la hacemos con un flujo o mejor aún: tirando código (que se factura por hora). No tiene ningún caso desacoplar, incluso cuando existen appliances para validar esquemas.
El chiste del outsourcing es quemar horas reinventando el hilo negro, divagando en arquitecturas y pelearse entre sí.
En fin, la culpa no la tiene el servicio.
Finito.
lunes, mayo 21, 2007
Oye Karacas
Hagamos un trato
¿Aceptas el trato?
Cuando sientas tu herida sangrar
cuando sientas tu voz sollozar
cuenta conmigo.
(de una canción de Carlos Puebla)
cuando sientas tu voz sollozar
cuenta conmigo.
(de una canción de Carlos Puebla)
Compañera,
usted sabe
que puede contar conmigo,
no hasta dos ni hasta diez
sino contar conmigo.
Si algunas veces
advierte
que la miro a los ojos,
y una veta de amor
reconoce en los míos,
no alerte sus fusiles
ni piense que deliro;
a pesar de la veta,
o tal vez porque existe,
usted puede contar
conmigo.
Si otras veces
me encuentra
huraño sin motivo,
no piense que es flojera
igual puede contar conmigo.
Pero hagamos un trato:
yo quisiera contar con usted,
es tan lindo
saber que usted existe,
uno se siente vivo;
y cuando digo esto
quiero decir contar
aunque sea hasta dos,
aunque sea hasta cinco.
No ya para que acuda
presurosa en mi auxilio,
sino para saber
a ciencia cierta
que usted sabe que puede
contar conmigo.
usted sabe
que puede contar conmigo,
no hasta dos ni hasta diez
sino contar conmigo.
Si algunas veces
advierte
que la miro a los ojos,
y una veta de amor
reconoce en los míos,
no alerte sus fusiles
ni piense que deliro;
a pesar de la veta,
o tal vez porque existe,
usted puede contar
conmigo.
Si otras veces
me encuentra
huraño sin motivo,
no piense que es flojera
igual puede contar conmigo.
Pero hagamos un trato:
yo quisiera contar con usted,
es tan lindo
saber que usted existe,
uno se siente vivo;
y cuando digo esto
quiero decir contar
aunque sea hasta dos,
aunque sea hasta cinco.
No ya para que acuda
presurosa en mi auxilio,
sino para saber
a ciencia cierta
que usted sabe que puede
contar conmigo.
Mario Benedetti
¿Aceptas el trato?
domingo, mayo 20, 2007
Ruby on Rails vs. PHP
No dejan de entretenerme. Lástima que hasta el siguiente lunes aparece el nuevo episodio.
Finito.
Finito.
viernes, mayo 18, 2007
Scott Hanselman's Computer Zen - Twittering my Diabetes
Scott Hanselman es un gran desarrollador, conferencista y escritor de tecnologias .NET, en particular ASP.NET y recientemente Windows CardSpace. Aparte de su conocido blog publica semanalmente un podcast del que habla de varios temas incluído el Open Source.
Lo empecé a leer por el aspecto de tecnología y después por sus experiencias como padre. Hubo un momento en que leí sobre su condición de diabético Tipo I. Entonces me quedé extremadamente sorprendido. Muchas personas en su condición han destruido su vida, tengo un familiar cercano que así lo hizo. Sin embargo Scott es un lider en muchos aspectos y es un modelo de padre y esposo a seguir.
Me motiva leerlo y ver la lucha en la que se ha embarcado contra la diabetes. En esta ocasión aprovecha el fenomeno twitter para compartir sus experiencias como diabético. Lo estaremos siguiendo.
Finito.
Lo empecé a leer por el aspecto de tecnología y después por sus experiencias como padre. Hubo un momento en que leí sobre su condición de diabético Tipo I. Entonces me quedé extremadamente sorprendido. Muchas personas en su condición han destruido su vida, tengo un familiar cercano que así lo hizo. Sin embargo Scott es un lider en muchos aspectos y es un modelo de padre y esposo a seguir.
Me motiva leerlo y ver la lucha en la que se ha embarcado contra la diabetes. En esta ocasión aprovecha el fenomeno twitter para compartir sus experiencias como diabético. Lo estaremos siguiendo.
Finito.
martes, mayo 15, 2007
Ruby vs. PHP: Sigue la mata dando
De la misma serie de videos promocionales de Ruby. Just watch it.
Finito.
Finito.
Habemus Mono
Se acaba de anunciar la liberación de la nueva versión 1.2.4 de Mono.
Entre las novedades más notables encontramos:
Finito.
Entre las novedades más notables encontramos:
- Más de 1,000 métodos agregados y/o actualizados
- Soporte completo de ASP.NET 2.0 (bueno... casi... los Web Parts siguen pendientes pero ¿a quién le importa?)
- Mejoras en el desempeño de ASP.NET
- Inicios de la implementación de C# 3.0
- Mono en Solaris/AMD64
- Y varios items más
Finito.
lunes, mayo 14, 2007
Ruby vs. Java Parte II
Al mismo estilo de los comerciales de Apple, Mac vs PC, estos tipos se han aventado un videito bastante chulo.
Finito.
Finito.
De nuevo con lo mismo: Patentes
Ayer apareció en varios medios la noticia de que Microsoft finalmente señalaba las violaciones a patentes en las que caen varios proyectos Open Source y Free Software.
El primer punto que me viene a la cabeza es la posición de desventaja que está empezando a mostrar Microsoft. A mi parecer, no es más que el resultado de no encontrar maneras de contrarestar la pérdida de posición que está sufriendo. Anteriormente comenté que los movimientos que está haciendo para entrar en otros mercados, más que una diversificación, demuestran que ya no es posible sustentar el modelo que los vino a hacer millonarios: el software propietario. Finalmente son una empresa y siendo pública tienen que otorgar dividendos. Ya no tienen mucho de donde sacarlos.
La siguiente idea es la válidez de las patentes. ¿Realmente sigue siendo válido este modelo? Cuando vemos que grandes y pequeñas empresas hacen valer su propiedad sobre las ideas, por más abstracta, sencilla y simple me pregunto: ¿Dónde va terminar esto? ¿Ya nadie va ser capaz de idear algo sin violar una patente? Existen casos donde podrá cuestionarse menos el modelo, la industria farmacéutica por ejemplo. Si no tienen el aliciente de explotar durante varios años una patente ¿qué los motivaría a inventar nuevos medicamentos? Pero en la industria del software ¿Por qué es válido patentar el algoritmo que hace que una sección de la pantalla parpadeé? ¿No es algo de total y simple sentido común?. La idea de un conjunto de componentes para generar páginas web ¿no es demasiado abstracta o genérica como para reclamarla como propia? No desconozco el derecho de la autoría, reclamo cancelar el derecho de la exclusividad.
Definitivamente urge una revisión profunda y real de este modelo.
Finito.
El primer punto que me viene a la cabeza es la posición de desventaja que está empezando a mostrar Microsoft. A mi parecer, no es más que el resultado de no encontrar maneras de contrarestar la pérdida de posición que está sufriendo. Anteriormente comenté que los movimientos que está haciendo para entrar en otros mercados, más que una diversificación, demuestran que ya no es posible sustentar el modelo que los vino a hacer millonarios: el software propietario. Finalmente son una empresa y siendo pública tienen que otorgar dividendos. Ya no tienen mucho de donde sacarlos.
La siguiente idea es la válidez de las patentes. ¿Realmente sigue siendo válido este modelo? Cuando vemos que grandes y pequeñas empresas hacen valer su propiedad sobre las ideas, por más abstracta, sencilla y simple me pregunto: ¿Dónde va terminar esto? ¿Ya nadie va ser capaz de idear algo sin violar una patente? Existen casos donde podrá cuestionarse menos el modelo, la industria farmacéutica por ejemplo. Si no tienen el aliciente de explotar durante varios años una patente ¿qué los motivaría a inventar nuevos medicamentos? Pero en la industria del software ¿Por qué es válido patentar el algoritmo que hace que una sección de la pantalla parpadeé? ¿No es algo de total y simple sentido común?. La idea de un conjunto de componentes para generar páginas web ¿no es demasiado abstracta o genérica como para reclamarla como propia? No desconozco el derecho de la autoría, reclamo cancelar el derecho de la exclusividad.
Definitivamente urge una revisión profunda y real de este modelo.
Finito.
miércoles, mayo 09, 2007
Entre servicios te veas
En una prueba de integración entre una aplicación .NET y otra desarrollada en Java nos apareció este mensaje:
¿Qué tiene de malo? (aparte de algunas faltas de ortografía) Son dos servicios que están intercambiando mensajes entre sí. No tienen interacción con el usuario, así que este tipo de mensajes, descriptivos y detallados, son completamente desaprovechados en este contexto.
Entonces ¿cuál es el modo correcto de devolver errores en este caso? No sé cual sea el modo correcto. Lo que a mi me gusta es el estilo de AppExchange Web Service API.
AppExchange (anteriormente conocida como Salesforce) es una empresa que ofrece software as a service (SaaS), en particular un CRM que compite directamente contra los grandes: Siebel, SAP y otros. Les ha ganado una gran tajada del mercado y sigue abriendo áreas de oportunidad. La API que comento la ofrecen mediante servicios web y tiene la funcionalidad de agregar, actualizar, borrar y buscar items de su mega repositorio de datos.
Así, en esas operaciones obviamente se envían y devuelven resultados en un contexto de integración de servicios. ¿Cómo le hacen? Va la referencia del API:
Tenemos la llamada create que recibe un arreglo de sObjects (tipo nativo de AppExchange) y como resultado devuelve un arreglo de objetos SaveResult. Ahora veamos SaveResult:
Nos devuelve un objeto con el identificador único (idField), una bandera de éxito o fracaso (successField) y un arreglo de objetos Error, igualmente veamos:
En fieldsField tenemos el o los nombres de los campos que provocaron el error; messageField es el texto descriptivo del error y finalmente statusCodeField que es el código que identifica el error dentro de un catálogo disponible en el WSDL del servicio.
Si bien tenemos un texto descriptivo, tenemos otras referencias (statusCodeField, successField) que nos permiten atender el problema y darle solución dentro de un contexto de integración.
A mi parecer es la falta de comprensión de los escenarios en los que se trabaja lo que provoca este tipo de diseños. Ya se requiere cambiar el modelo y empezar a modelar servicios. En algún momento habrá un servicio que se encargue de interactuar con el usuario y habrá que darle la suficiente información para que resuelva los problemas que lleguen a aparecer.
Por eso, entre servicios te veas, comportate como un servicio.
Finito.
Exito: 0
Código Error: 100
Desc. Error: mx.gob.imss.sigoi.quejaVerbal.exception.ValidaCampoException:
El campo Calidad de la persona que se comunica es requerido.
El campo Nombre de la persona que se comunica es requerido.
El campo Apellido paterno de la persona que se comunica es requerido.
El campo Lada de teléfono particular de la persona que se comunica tiene que ser numérico.
El campo Lada de teléfono particular de la persona que se comunica tiene una longitud no valida, menor a 2 Caracteres
El campo Teléfono particular de la persona que se comunica tiene que ser numérico.
El campo Teléfono particular de la persona que se comunica tiene una longitud no valida, menor a 8 Caracteres
El campo Teléfono celular de la persona que se comunica tiene que ser numérico.
El campo Teléfono celular de la persona que se comunica tiene una longitud no valida, menor a 12 Caracteres
El campo Correo electrónico de la persona que se comunica no tiene un formato adecuado
Se tiene que incluir al menos un medio de contacto valido de la persona que se
comunica: Lada y número de teléfono particular, número de teléfono celular, correo electrónico, o dirección completa
Es necesario capturar el NSS de la persona que se comunica
Es necesario capturar el NSS de la persona que solicita el servicio
El campo Calidad de la persona que solicita el servicio es requerido.
El campo Teléfono celular del usuario que solicita el servicio tiene que ser numérico.
El campo Teléfono celular del usuario que solicita el servicio tiene una longitud no valida, menor a 12 Caracteres
El campo Entidad federativa del usuario que solicita el servicio tiene que ser numérico.
El campo Entidad federativa del usuario que solicita el servicio no es un valor válido de catálogo
El campo Clasificación de la solicitud del planteamiento tiene que ser numérico.
El campo Clasificación de la solicitud del planteamiento no es un valor válido de catálogo
El campo Tema del planteamiento tiene que ser numérico.
El campo Tema del planteamiento no es un valor válido de catálogo
El campo Subtema del planteamiento tiene que ser numérico.
El campo Subtema del planteamiento no es un valor válido de catálogo
El campo Delegación de Adscripción del planteamiento no es un valor válido de catálogo
El campo Unidad Medica de Adscripción del planteamiento tiene que ser numérico.
El campo Unidad Medica de Adscripción del planteamiento no es un valor válido de catálogo
El campo Delegación o UMAE involucrada en la gestión o queja del planteamiento tiene que ser numérico.
El campo Delegación o UMAE involucrada en la gestión o queja del planteamiento no es un valor válido de catálogo
El campo Subdeleación y/o Unidad involucrada en la gestión o queja del planteamiento tiene que ser numérico.
El campo Subdeleación y/o Unidad involucrada en la gestión o queja del planteamiento no es un valor válido de catálogo
¿Qué tiene de malo? (aparte de algunas faltas de ortografía) Son dos servicios que están intercambiando mensajes entre sí. No tienen interacción con el usuario, así que este tipo de mensajes, descriptivos y detallados, son completamente desaprovechados en este contexto.
Entonces ¿cuál es el modo correcto de devolver errores en este caso? No sé cual sea el modo correcto. Lo que a mi me gusta es el estilo de AppExchange Web Service API.
AppExchange (anteriormente conocida como Salesforce) es una empresa que ofrece software as a service (SaaS), en particular un CRM que compite directamente contra los grandes: Siebel, SAP y otros. Les ha ganado una gran tajada del mercado y sigue abriendo áreas de oportunidad. La API que comento la ofrecen mediante servicios web y tiene la funcionalidad de agregar, actualizar, borrar y buscar items de su mega repositorio de datos.
Así, en esas operaciones obviamente se envían y devuelven resultados en un contexto de integración de servicios. ¿Cómo le hacen? Va la referencia del API:
SaveResult[] = sfdc.create(sObject[] sObjects);
Tenemos la llamada create que recibe un arreglo de sObjects (tipo nativo de AppExchange) y como resultado devuelve un arreglo de objetos SaveResult. Ahora veamos SaveResult:
private Error[] errorsField;
private string idField;
private bool successField;
Nos devuelve un objeto con el identificador único (idField), una bandera de éxito o fracaso (successField) y un arreglo de objetos Error, igualmente veamos:
private string[] fieldsField;
private string messageField;
private StatusCode statusCodeField;
En fieldsField tenemos el o los nombres de los campos que provocaron el error; messageField es el texto descriptivo del error y finalmente statusCodeField que es el código que identifica el error dentro de un catálogo disponible en el WSDL del servicio.
Si bien tenemos un texto descriptivo, tenemos otras referencias (statusCodeField, successField) que nos permiten atender el problema y darle solución dentro de un contexto de integración.
A mi parecer es la falta de comprensión de los escenarios en los que se trabaja lo que provoca este tipo de diseños. Ya se requiere cambiar el modelo y empezar a modelar servicios. En algún momento habrá un servicio que se encargue de interactuar con el usuario y habrá que darle la suficiente información para que resuelva los problemas que lleguen a aparecer.
Por eso, entre servicios te veas, comportate como un servicio.
Finito.
sábado, mayo 05, 2007
¿Qué pasa? ¿Qué pasó? ¿Qué pasará?
Cada vez que quedamos para vernos
cuando apareces se me estremece el cuerpo
te has convertido en lo más alucinante
lo que aprecio en mi vida lo importante
Estás y siento cuando estoy a tu lado
una tortura si estamos separados
quiero quedarme siempre junto a ti
cada día te quiero más
cada día te quiero un poco más
cada día te quiero más
cada día te quiero un poco más
cada día te quiero más
cada día nos queremos más
No es la primera vez esta semana
que te dejas abierta la ventana
el baño como una verbena
te has olvidado tirar de la cadena
(Se que esta noche a la vuelta del trabajo me tocará de nuevo hacer la cena)
Egoísta, insoportable no me gusta
que me trates así
cada día te ignoro más
cada día te ignoro un poco más
cada día te ignoro más
cada día nos ignoramos ignoramos más
No me apetece estar siempre de bronca
por cualquier cosa tenemos una gorda
ya no puedo aguantar otro cabreo
estoy mucho mejor si no te veo
No me preocupa lo que pienses esta noche
cuando al regreso no encuentres el coche
me he marchado para siempre
no quiero volver a verte jamás
(Hasta luego Lucas)
Cada día te odio más
cada día te odio un poco más
cada día te odio más
cada día nos odiamos más
(Hasta que la muerte les separe)
Cada día te quiero más
cada día te odio un poco más
cada día te quiero más
cada día nos queremos nos odiamos
nos queremos nos odiamos más
cuando apareces se me estremece el cuerpo
te has convertido en lo más alucinante
lo que aprecio en mi vida lo importante
Estás y siento cuando estoy a tu lado
una tortura si estamos separados
quiero quedarme siempre junto a ti
cada día te quiero más
cada día te quiero un poco más
cada día te quiero más
cada día te quiero un poco más
cada día te quiero más
cada día nos queremos más
No es la primera vez esta semana
que te dejas abierta la ventana
el baño como una verbena
te has olvidado tirar de la cadena
(Se que esta noche a la vuelta del trabajo me tocará de nuevo hacer la cena)
Egoísta, insoportable no me gusta
que me trates así
cada día te ignoro más
cada día te ignoro un poco más
cada día te ignoro más
cada día nos ignoramos ignoramos más
No me apetece estar siempre de bronca
por cualquier cosa tenemos una gorda
ya no puedo aguantar otro cabreo
estoy mucho mejor si no te veo
No me preocupa lo que pienses esta noche
cuando al regreso no encuentres el coche
me he marchado para siempre
no quiero volver a verte jamás
(Hasta luego Lucas)
Cada día te odio más
cada día te odio un poco más
cada día te odio más
cada día nos odiamos más
(Hasta que la muerte les separe)
Cada día te quiero más
cada día te odio un poco más
cada día te quiero más
cada día nos queremos nos odiamos
nos queremos nos odiamos más
SpiderMan 3
Hoy fuimos al tan esperado estreno de SpiderMan 3. Mucha gente. Mucha emoción. Muchos promos de las películas de este verano.
Sentí larga la peli. De por sí se me hace que comprimen 15 o 20 años de historia del comic en dos horas pero esta vez abusaron. El screen play se tomó bastante libertades. No mantienen sincronía entre los personajes ¿Gwen Stacy viva cuando Harry Osborn Jr es El Duende Verde? ¿El ser simbiótico que llegó del espacio?
Las escenas de acción, igual que los anteriores filmes simplemente estuvieron super. El Arenero y Venom, villanos clásicos. La Tía May ¿quién no quisiera una tía así? MJ linda como desde el primer episodio. Gwen Stacy una hermosa novedad. Peter Parker en el lado oscuro, gracioso al inicio, aburrido al final. El Hombre Araña frente a la bandera gringa: el peor momento de la película.
¿Entonces por qué me gusta el Hombre Araña? Por humano. Cuando se sienta a sacarse toda la arena que tragó y que se quedó en su traje se me hizo tan.... común. Cuando siente que ya regó el tepache y llega la Tía May a darle la palmadita en la espalda es tan... común. Cuando se siente engañado por Harry y lo va a buscar a su casa y se pelean, también es tan común que solo por los mega-trancazos te ubicas que es una película.
La enseñanzas de la Tía May y el Tío Ben son la mejor parte de la película y crean todo el personaje de SpiderMan. Otra cosa que han olvidado incluir en los guiones es que al fin y al cabo Peter Parker es un nerd. Recuerdo que en los comics a veces salía con una explicación "científica" sobre como venció a su enemigo en turno.
En lo particular no me gustó del todo. Espero que la siguiente sea mejor. Recuerdan al Lagarto ¿o mejor le decimos Dr. Connor?
Finito.
Sentí larga la peli. De por sí se me hace que comprimen 15 o 20 años de historia del comic en dos horas pero esta vez abusaron. El screen play se tomó bastante libertades. No mantienen sincronía entre los personajes ¿Gwen Stacy viva cuando Harry Osborn Jr es El Duende Verde? ¿El ser simbiótico que llegó del espacio?
Las escenas de acción, igual que los anteriores filmes simplemente estuvieron super. El Arenero y Venom, villanos clásicos. La Tía May ¿quién no quisiera una tía así? MJ linda como desde el primer episodio. Gwen Stacy una hermosa novedad. Peter Parker en el lado oscuro, gracioso al inicio, aburrido al final. El Hombre Araña frente a la bandera gringa: el peor momento de la película.
¿Entonces por qué me gusta el Hombre Araña? Por humano. Cuando se sienta a sacarse toda la arena que tragó y que se quedó en su traje se me hizo tan.... común. Cuando siente que ya regó el tepache y llega la Tía May a darle la palmadita en la espalda es tan... común. Cuando se siente engañado por Harry y lo va a buscar a su casa y se pelean, también es tan común que solo por los mega-trancazos te ubicas que es una película.
La enseñanzas de la Tía May y el Tío Ben son la mejor parte de la película y crean todo el personaje de SpiderMan. Otra cosa que han olvidado incluir en los guiones es que al fin y al cabo Peter Parker es un nerd. Recuerdo que en los comics a veces salía con una explicación "científica" sobre como venció a su enemigo en turno.
En lo particular no me gustó del todo. Espero que la siguiente sea mejor. Recuerdan al Lagarto ¿o mejor le decimos Dr. Connor?
Finito.
jueves, mayo 03, 2007
Conceptos de Escritorio
Uno de los temas en los que debrayamos cañon el sábado anterior durante el FLISOL fue la manipulación de la información. Hablamos sobre las metáforas que se utilizan para representar acciones en la PC.
Por ejemplo, cuando quiero escribir una carta, tomo una hoja de papel y un lápiz y simplemente empiezo a escribir. En cambio para escribir un libro, lo más normal sería tomar una máquina de escrebir y tirar teclazos. En ninguno de los dos casos me preocupo, hasta que es estrictamente necesario, de cuestiones de márgenes, paginado, tablas, bullets, etc, etc, etc.
El modelo que usamos para el procesador de texto está tomado de la industria de la impresión, el Desktop Publishing ¿alguien se acuerda del PageMaker? ¿Ventura? Estos programas se hicieron para profesionales de la impresión, sin embargo a alguien se le ocurrió que también podrían funcionar para el usuario común y corriente que escribe cartas, memos, oficios y demás papelitos. ¿Quién, a la fecha, usa más del 1% de la funcionalidad de cualquier Procesador de Textos?
De igual manera, la interface que tenemos de entrada en casi cualquier PC es un escritorio. Plano. 2D. Más bien la representación de un escritorio. Y se tiene que mejorar esa interface para facilitar todavía más el acceso a una computadora.
A continuación incluyo un video que postearon la Cofradia que muestra otro tipo de escritorio, un poco más cercano a la realidad.
Finito.
Por ejemplo, cuando quiero escribir una carta, tomo una hoja de papel y un lápiz y simplemente empiezo a escribir. En cambio para escribir un libro, lo más normal sería tomar una máquina de escrebir y tirar teclazos. En ninguno de los dos casos me preocupo, hasta que es estrictamente necesario, de cuestiones de márgenes, paginado, tablas, bullets, etc, etc, etc.
El modelo que usamos para el procesador de texto está tomado de la industria de la impresión, el Desktop Publishing ¿alguien se acuerda del PageMaker? ¿Ventura? Estos programas se hicieron para profesionales de la impresión, sin embargo a alguien se le ocurrió que también podrían funcionar para el usuario común y corriente que escribe cartas, memos, oficios y demás papelitos. ¿Quién, a la fecha, usa más del 1% de la funcionalidad de cualquier Procesador de Textos?
De igual manera, la interface que tenemos de entrada en casi cualquier PC es un escritorio. Plano. 2D. Más bien la representación de un escritorio. Y se tiene que mejorar esa interface para facilitar todavía más el acceso a una computadora.
A continuación incluyo un video que postearon la Cofradia que muestra otro tipo de escritorio, un poco más cercano a la realidad.
Finito.
martes, mayo 01, 2007
FLISOL 2007
El sábado anterior se realizó el evento FLISOL y me anoté para participar como voluntario en la Sede Ecatepec. Aunque las actividades estaban programadas a partir de las 9.00 la verda' es que llegué hasta las 12.30 +/-.
Me llamó la atención el hecho de que fue un pequeño cibercafé con máquinas Linux y otras Windows. El anfitrión, Jonathan, es un chavo tranquilo y buena onda. Hubo un caso de un modem SmartLink que nomás no se dejó configurar, estuve batallando para compilar el driver pero a la hora y media me rendí y entró Marcos al relevo. Tampoco hubo éxito.
Otro asistente, Carlos, se la pasó probando distros en su laptop. Fácil probó alrededor de 10 y fue haciendo los comentarios acerca del reconocimiento de hw, que es el tema de su interés.
Jonathan tuvo el detalle de invitarnos unas ricas tostadas e hicimos un break para platicar y comer. Despuecito regresamos y Marcos nos dió una breve introducción a Magic Point. Es un programa harto interesante. Mediante un metalenguaje se define una presentación completa. Una de las inquietudes de Marcos es desarrollar un editor GUI para hacer las presentaciones y a mi se me ocurré hacerlo funcionar en Windows. Sería un golpe muy rudo para PowerPoint :D
Alrededor de las 17.30 me salí y hasta en eso hubo anécdota. A los pocos minutos de subir al camión, sentí que me tocaron el hombro e inmediatamente volteé para ver a un chavo mostrandomé el pecho con un logo de "Linux inside" :S ¡Qué pex!
Pues resulta que se trataba nada más que de Gaper y BRIO que iban regresando de la Sede Tecámac. Los conocía de "nombre" y me dió un gusto enorme platicar sobre la experiencia del FLISOL hasta que me tuve que bajar por que ya había llegado a mi destino.
Fue un día padre, tranquilo y muy geek hablando de escritorios, drivers, ideas, experiencias y sobre todo conociendo a otros linuxeros. Espero seguir manteniendo contacto con ellos.
Finito.
Me llamó la atención el hecho de que fue un pequeño cibercafé con máquinas Linux y otras Windows. El anfitrión, Jonathan, es un chavo tranquilo y buena onda. Hubo un caso de un modem SmartLink que nomás no se dejó configurar, estuve batallando para compilar el driver pero a la hora y media me rendí y entró Marcos al relevo. Tampoco hubo éxito.
Otro asistente, Carlos, se la pasó probando distros en su laptop. Fácil probó alrededor de 10 y fue haciendo los comentarios acerca del reconocimiento de hw, que es el tema de su interés.
Jonathan tuvo el detalle de invitarnos unas ricas tostadas e hicimos un break para platicar y comer. Despuecito regresamos y Marcos nos dió una breve introducción a Magic Point. Es un programa harto interesante. Mediante un metalenguaje se define una presentación completa. Una de las inquietudes de Marcos es desarrollar un editor GUI para hacer las presentaciones y a mi se me ocurré hacerlo funcionar en Windows. Sería un golpe muy rudo para PowerPoint :D
Alrededor de las 17.30 me salí y hasta en eso hubo anécdota. A los pocos minutos de subir al camión, sentí que me tocaron el hombro e inmediatamente volteé para ver a un chavo mostrandomé el pecho con un logo de "Linux inside" :S ¡Qué pex!
Pues resulta que se trataba nada más que de Gaper y BRIO que iban regresando de la Sede Tecámac. Los conocía de "nombre" y me dió un gusto enorme platicar sobre la experiencia del FLISOL hasta que me tuve que bajar por que ya había llegado a mi destino.
Fue un día padre, tranquilo y muy geek hablando de escritorios, drivers, ideas, experiencias y sobre todo conociendo a otros linuxeros. Espero seguir manteniendo contacto con ellos.
Finito.
Suscribirse a:
Entradas (Atom)