Leí muchos comentarios al respecto del tipo "ni Microsoft hace ese tipo de cosas", "por que si pagué por el dispositivo me cobran también las actualizaciones", "son solo unos cambios menores para mi, no los necesito". Pero lo cierto es que esos argumentos están incompletos. Creo que lo mas grave es otra cosa, mucho mas importante aún, y mucho mas cara.
Creo que el tema se tiene que centrar en la estafa que resulta para la gente que compra aplicaciones. Es muy simple, Apple te quema la cabeza con la venta de aplicaciones, vos vas, te compras una aplicación para tu iPod Touch, la usas, te acostumbras a ella, la consumis a diario, cada tanto la actualizan, mejoran cosas, agregan funcionalidad, corrijen bugs, etc. Pagaste por esa aplicación y todo lo que pase con ella en adelante.
Que pasa, un día como hoy, a Apple se le ocurre sacar un "major update" del sistema operativo, y le agregan la amigable idea de cobrar por ese Update. Los desarrolladores de esas aplicaciones van a aprovechar esas funcionalidades nuevas, para mejorar su producto final y dar mayor valor agregado a su aplicación. Que pasa ahi, quien no quiere pagar por un update del sistema operativo, no solo no va a poder aprovechar de ese Update que se le haga a la aplicación, sino que ademas se va a perder de cualquier corrección, parche de seguridad, bug, etc que pueda llegar a aparecer y que sea resuelto en versiones posteriores.
Ahora, es culpa del desarrollador? digo, por utilizar funcionalidades que no estan disponibles en todas las versiones del OS, y que pueden ser incompatibles para esta minoría. Mi opinión es que NO, la culpa queda total y completamente del lado de Apple...
Apple es quien impulsa a los desarrolladores a utilizar estas nuevas funcionalidades, entonces porque al desarrollador de X aplicacion se le ocurrió dar soporte bluetooth para un elemento externo, ahora el usuario de iPod touch que no quizo pagar el precio de un update de OS no puede "disfrutar" (o dejar de sufrir) la corrección de un bug que generaba una molestia a la hora de usar esa aplicacion.
Y que se entienda, el problema tampoco es que Apple impulse el uso de esas nuevas funcionalidades y nuevos frameworks, el problema es que pretenda cobrar actualizaciones por el mero hecho de que "con el iPod Touch no monetiza tanto como con el iPhone", lo cual es lógico, con el iPhone gana por la compra de aplicaciones, compra de música y videos, y por la transferencia de datos, con el iPod Touch no, pero es eso culpa del pobre diablo que decidió comprarse un iPod Touch?
2008-05-22
Sobre Shared Items en Google Reader
(Para el que no sepa que se puede sharear en Google Reader, o para el que no sepa que es Google Reader: http://googlesystem.blogspot.com/2008/05/share-and-annotate-web-pages-in-google.html)
Dos cosas:
Todavía no termino de entender/descubrir si sharear muchos items le rompe las pelotas a mis contactos. Es algo simil a lo que me pasó cuando arranqué con los mensajes de texto: "En que contexto no rompe las pelotas mandar un mensajes de texto?".
So, mas alla de que pienso seguir shareando como loco todo lo que me llame la atención ( :D ), creo que la funcionalidad está muy buena, pero que podría ser MUCHO MEJOR si implementaran dos cosillas mas: (a parar las orejas Mountain View [?!])
a) Posibilidad de "suscribirse" a los shared items: El hecho de que el shared item se mezcle con tus items no me divierte mucho. Que conozca gente de variados intereses no quiere decir que los comparta. Sería bueno poder suscribirse a un shared item, y que si no estas suscripto, te informe de forma muy discreta que un amigo tuyo esta shareando cosas.
b) Shareo por categorías: Se complementa perfecto con el punto a). Si shareo cosas de política, tecnología, comic strips, blah, es muy probable que haya mucha gente a la cual, no solo no le llame la atención el tema, sino que ademas le moleste el shareo. Sería ideal que uno pueda asignarle, no se, tal vez mediante los tags, que hoy en día ya están implementados, algunos tags "clave" a sharear. Por ende, debajo del nombre de tu "amigo shareando items" en reader, aparecería un listado de "tags clave", donde uno podría elegir si quiere o no "suscribirse" a ese tag de tu "amigo".
Esas dos cosas me limitan a la hora de sharear desaforadamente (y eso que ya shareo bastante :D).
Dos cosas:
Todavía no termino de entender/descubrir si sharear muchos items le rompe las pelotas a mis contactos. Es algo simil a lo que me pasó cuando arranqué con los mensajes de texto: "En que contexto no rompe las pelotas mandar un mensajes de texto?".
So, mas alla de que pienso seguir shareando como loco todo lo que me llame la atención ( :D ), creo que la funcionalidad está muy buena, pero que podría ser MUCHO MEJOR si implementaran dos cosillas mas: (a parar las orejas Mountain View [?!])
a) Posibilidad de "suscribirse" a los shared items: El hecho de que el shared item se mezcle con tus items no me divierte mucho. Que conozca gente de variados intereses no quiere decir que los comparta. Sería bueno poder suscribirse a un shared item, y que si no estas suscripto, te informe de forma muy discreta que un amigo tuyo esta shareando cosas.
b) Shareo por categorías: Se complementa perfecto con el punto a). Si shareo cosas de política, tecnología, comic strips, blah, es muy probable que haya mucha gente a la cual, no solo no le llame la atención el tema, sino que ademas le moleste el shareo. Sería ideal que uno pueda asignarle, no se, tal vez mediante los tags, que hoy en día ya están implementados, algunos tags "clave" a sharear. Por ende, debajo del nombre de tu "amigo shareando items" en reader, aparecería un listado de "tags clave", donde uno podría elegir si quiere o no "suscribirse" a ese tag de tu "amigo".
Esas dos cosas me limitan a la hora de sharear desaforadamente (y eso que ya shareo bastante :D).
2008-02-13
Task Managers para exploradores
¿Que tan loca e inutil es la idea de implementar task managers en los exploradores Web?.
No hay que ser muy observador para notar que las RIA están en franco ascenso. El hecho de que esto pase, da lugar al desarrollo de decenas de Frameworks como los existentes hoy en día.
Estos Framework, en pos de facilitar el trabajo del desarrollador final, y de ser compatible con la extensa gama de navegadores que hay en mercado, agregan cada vez mas lineas de código. De mas está decir que ese codigo luego será ejecutado del lado del cliente.
El hecho de que sea JavaScript un lenguaje de scripting tan flexible como efectivamente lo es, no es gratis. Cualquier operación que se realize (asignaciones de memoria, llamadas a una funciones, cualquier creación de un nuevo objeto [sobre todo teniendo en cuenta el modelo de objetos que JS utiliza]) es considerablemente mas pesada que esa misma operación llevada a otro lenguaje. A esto se le suma que las herramientas de debug disponibles para JavaScript no son extremadamente robustas. No quiere decir que no las haya, particularmente considero que FireBug es una herramienta fundamental tanto para los diseñadores, como para los programadores JavaScript.
Si bien es cierto que todos los navegadores tienen cosas por hacer en la optimización de sus interpretes de JavaScript, y que el trabajo no está terminado en ese aspecto, creo que no estaría nada mal que cada desarrollador pueda tener conocimiento de cual es la demanda de recursos que están teniendo sus sitios en cada navegador, sino que tambien me parece importante que quienes navegan esos sitios, puedan determinar si quieren realmente que determinado porcentaje de su procesador se desperdicie en visualizar ese sitio.
Un ejemplo muy claro es el traspaso de GMail 1 a GMail 2. Creo que todos los que aprecian la interface de GMail, están muy contentos con los cambios que se implementaron desde GMail 1 a GMail 2, y también creo que todos los usuarios de GMail 2 notaron el IMPORTANTE aumento de consumo de recursos por parte de este último. No sería válido poder tener un dato especifico de que tan pesado es, para que los desarrolladores puedan tener en cuenta cuales son los factores que provocan ese peso (y lograr optimizaciones), y que los usuarios puedan saber cual es el sitio de todos los que tienen abiertos que está generando un consumo excesivo de recursos?.
Si realmente son Aplicaciones Web, suponemos, entonces, que los navegadores son nuestros Sistemas Operativos Web. No sería bueno tener un mayor control sobre que es lo que hace nuestro Sistema Operativo Web?
Definitivamente es algo que falta, y no estaría nada mal.
No hay que ser muy observador para notar que las RIA están en franco ascenso. El hecho de que esto pase, da lugar al desarrollo de decenas de Frameworks como los existentes hoy en día.
Estos Framework, en pos de facilitar el trabajo del desarrollador final, y de ser compatible con la extensa gama de navegadores que hay en mercado, agregan cada vez mas lineas de código. De mas está decir que ese codigo luego será ejecutado del lado del cliente.
El hecho de que sea JavaScript un lenguaje de scripting tan flexible como efectivamente lo es, no es gratis. Cualquier operación que se realize (asignaciones de memoria, llamadas a una funciones, cualquier creación de un nuevo objeto [sobre todo teniendo en cuenta el modelo de objetos que JS utiliza]) es considerablemente mas pesada que esa misma operación llevada a otro lenguaje. A esto se le suma que las herramientas de debug disponibles para JavaScript no son extremadamente robustas. No quiere decir que no las haya, particularmente considero que FireBug es una herramienta fundamental tanto para los diseñadores, como para los programadores JavaScript.
Si bien es cierto que todos los navegadores tienen cosas por hacer en la optimización de sus interpretes de JavaScript, y que el trabajo no está terminado en ese aspecto, creo que no estaría nada mal que cada desarrollador pueda tener conocimiento de cual es la demanda de recursos que están teniendo sus sitios en cada navegador, sino que tambien me parece importante que quienes navegan esos sitios, puedan determinar si quieren realmente que determinado porcentaje de su procesador se desperdicie en visualizar ese sitio.
Un ejemplo muy claro es el traspaso de GMail 1 a GMail 2. Creo que todos los que aprecian la interface de GMail, están muy contentos con los cambios que se implementaron desde GMail 1 a GMail 2, y también creo que todos los usuarios de GMail 2 notaron el IMPORTANTE aumento de consumo de recursos por parte de este último. No sería válido poder tener un dato especifico de que tan pesado es, para que los desarrolladores puedan tener en cuenta cuales son los factores que provocan ese peso (y lograr optimizaciones), y que los usuarios puedan saber cual es el sitio de todos los que tienen abiertos que está generando un consumo excesivo de recursos?.
Si realmente son Aplicaciones Web, suponemos, entonces, que los navegadores son nuestros Sistemas Operativos Web. No sería bueno tener un mayor control sobre que es lo que hace nuestro Sistema Operativo Web?
Definitivamente es algo que falta, y no estaría nada mal.
2008-02-12
Intento de Blog #260658
Para arrancar mi intento de Blog #260658, repito por 260657 vez, que los templates de Blogger son realmente chotos.
No es que ya esté cansado de verlos en cuanto blog aparezca por ahi, ni que estén "pasados de moda"... El 90% de estos templates pueden ser calificados de HORRIBLES desde 1997 para acá. Son, esteticamente, antiesteticos. Con la guita que factura Google con AdWords llama la atención que no hayan puesto unos verdes para hacer templates que valgan la pena.
Igual no importa. Poco tiene que ver lo lindo o feo del asunto, si lo que importa acá es "que tan feo es el contenido", y no "que tan feo se vé". Lo que importa es lo de adentro decía Sprite, mientras te empomaba la botellita de 600 a $2.50.
Esta vez, voy a intentar utilizar una técnica un tanto diferente a la que usé en mis anteriores Blogs. Prometo releer un 90% menos los posts antes de enviarlos. El problema no radica en que no se me ocurran cosas que poner en un blog. Por el contrario, mi cabeza está llena de boludeces por publicar, pero mi dispersión, mi constancia (o mas bien, mi no-constancia) y mi obsesión por corregir y doble-chequear cuanto dato quiera publicar, hacen que mis blogs sean un fracaso tras otro. No puedo tardar 2 horas en hacer un post de 4 o 5 parrafos. Doy asco.
Por eso en este intento de blog, me va a chupar todo un huevo. Si quieren ver: faltas de ortografía, desinformación, una pésima redacción, pueden darse una vuelta por InfoBAE o por acá.
He dicho.
No es que ya esté cansado de verlos en cuanto blog aparezca por ahi, ni que estén "pasados de moda"... El 90% de estos templates pueden ser calificados de HORRIBLES desde 1997 para acá. Son, esteticamente, antiesteticos. Con la guita que factura Google con AdWords llama la atención que no hayan puesto unos verdes para hacer templates que valgan la pena.
Igual no importa. Poco tiene que ver lo lindo o feo del asunto, si lo que importa acá es "que tan feo es el contenido", y no "que tan feo se vé". Lo que importa es lo de adentro decía Sprite, mientras te empomaba la botellita de 600 a $2.50.
Esta vez, voy a intentar utilizar una técnica un tanto diferente a la que usé en mis anteriores Blogs. Prometo releer un 90% menos los posts antes de enviarlos. El problema no radica en que no se me ocurran cosas que poner en un blog. Por el contrario, mi cabeza está llena de boludeces por publicar, pero mi dispersión, mi constancia (o mas bien, mi no-constancia) y mi obsesión por corregir y doble-chequear cuanto dato quiera publicar, hacen que mis blogs sean un fracaso tras otro. No puedo tardar 2 horas en hacer un post de 4 o 5 parrafos. Doy asco.
Por eso en este intento de blog, me va a chupar todo un huevo. Si quieren ver: faltas de ortografía, desinformación, una pésima redacción, pueden darse una vuelta por InfoBAE o por acá.
He dicho.
Suscribirse a:
Entradas (Atom)