¿En qué pensaban cuando diseñaron la PDA ipaq 214? Teniendo en cuenta que la mayoría de la gente va a comprarla como agenda, para usar su software de navegación favorita, etc, por qué coño no incluisteis un puerto serie? ¿qué protocolo creeis que usan los GPS?
Hay decisiones que nunca entenderé.
9.30.2008
9.16.2008
De menos a más
La programación web no ha sido lo mio, aunque tengo que reconocer que cada día me atrae más, no tanto la parte front end, el interfaz de usuario, javascripts, html y tecnologías varias, si no la parte de servicio.
Para llevar un tracking de los usuarios de demos agroguía implementé un sistema de tracking muy rudimentario, la herramienta enviaba -de alguna forma, no voy a revelar el secreto, aunque si sigues el blog sabrás como- datos a un servicio web (http más bien). Cuando planeé el servicio estaba pensado para funcionar, siempre y cuando no hubiese accesos recurrentes.
Con ese requisito, hice un script cgi en dos minutos que me ha funcionado hasta hace una semana. Desde hace una semana tengo una cantidad razonable de peticiones al server, las justas para que haya posibilidad de accesos múltiples al mismo tiempo, de forma que los datos se han corrompido.
La pregunta es la siguiente: hubiera merecido la pena hacer el servicio bien desde el principio o es preferible trabajar dos veces?.
Los puristas responderían sin dudarlo: "deberías haber hecho las cosas bien y planificarlo para el futuro", los pragmáticos hubieran hecho lo que yo hice :). Si analizas bien la aplicación te das cuenta que la probabilidad de accesos recurrentes era bajísima y la probabilidad de perder los datos muy baja (teniendo en cuenta los backups del server) y el valor de los datos bajo, con lo cual no merecía la pena.
Vale, pero ahora te toca hacer lo que no hiciste hace tiempo, con lo cual si lo hubieras hecho hace un tiempo ahora no tendrías problemas. FALSO, porque con esa herramienta de dos minutos que ha funcionado a modo de test he aprendido ciertas cosas -el know how famoso- que ahora voy a tener en cuenta. Esa es la principal razón de no intentar hacer todo desde el principio, cosa que he visto repetida cientos de veces en diferentes entornos empresariales.
Moraleja: "no trates de correr antes de aprender a andar"
Para llevar un tracking de los usuarios de demos agroguía implementé un sistema de tracking muy rudimentario, la herramienta enviaba -de alguna forma, no voy a revelar el secreto, aunque si sigues el blog sabrás como- datos a un servicio web (http más bien). Cuando planeé el servicio estaba pensado para funcionar, siempre y cuando no hubiese accesos recurrentes.
Con ese requisito, hice un script cgi en dos minutos que me ha funcionado hasta hace una semana. Desde hace una semana tengo una cantidad razonable de peticiones al server, las justas para que haya posibilidad de accesos múltiples al mismo tiempo, de forma que los datos se han corrompido.
La pregunta es la siguiente: hubiera merecido la pena hacer el servicio bien desde el principio o es preferible trabajar dos veces?.
Los puristas responderían sin dudarlo: "deberías haber hecho las cosas bien y planificarlo para el futuro", los pragmáticos hubieran hecho lo que yo hice :). Si analizas bien la aplicación te das cuenta que la probabilidad de accesos recurrentes era bajísima y la probabilidad de perder los datos muy baja (teniendo en cuenta los backups del server) y el valor de los datos bajo, con lo cual no merecía la pena.
Vale, pero ahora te toca hacer lo que no hiciste hace tiempo, con lo cual si lo hubieras hecho hace un tiempo ahora no tendrías problemas. FALSO, porque con esa herramienta de dos minutos que ha funcionado a modo de test he aprendido ciertas cosas -el know how famoso- que ahora voy a tener en cuenta. Esa es la principal razón de no intentar hacer todo desde el principio, cosa que he visto repetida cientos de veces en diferentes entornos empresariales.
Moraleja: "no trates de correr antes de aprender a andar"
9.13.2008
¿dónde están los técnicos?
Llevo ya algún tiempo siguiendo blogs personales de gente que se dedica a negocios en internet como por ejemplo Carlos Blanco, Rodolfo Carpintier y Alejandro Suárez Sánchez-Ocaña, Me gusta seguirlos porque saben del tema, saben transimitirlo bien y además lo hacen desde una visión cercana. Es fácil ver posts personales, de sus vacaciones, etc, que a priori no tienen mucho que ver con su profesión, pero que resultan también interesantes porque te pone un poco en el contexto de la vida del blogger en cuestión.
Pero hay una cosa que me mata y me molesta profundamente, y es la poca consideración, atención, protagonismo, llámalo como quieras, que dan a las personas de la parte técnica, a la producción real del producto. Casi siempre los elogios, comentarios positivos son a los que han puesto el dinero, los que han dirigido el desarrollo, los que han vendido, etc, a los que no quito mérito, pero es que al igual que sin ellos no habría nada, sin nosotros los técnicos, tampoco lo habría. Somos los productores de la materia prima, ¿por qué siempre los primeros de la cadena somos los peor considerados?.
Pongamos un ejemplo, hace poco se presentaba yes.fm, del cual Alejando Suárez es socio fundador, y no hace demasiado tiempo enumeraba al equipo de yes.fm. Bien, ni un solo técnico, mínimo creo yo, una reseña al director técnico o similar. Se lo recriminé en un comentario, al cual me respondió que haría un post sobre ello, el cual aún estoy esperando, y no soy el único (lee los comentarios del post). Admito que se lo han currando mucho en cuanto a la parte de marketing, etc, tiene pinta de ser algo bueno, pero es que creo que es un proyecto técnicamente también muy ambiciosos, digno de reseña.
Cierto es que hay pequeñas reseñas, por ejemplo Rodolfo hizo un par de post este verano, en los cuales participé sobre el tema de los programadores y técnicos varios:
- hablando de programadores. En este post se demuestra que la visión de un técnico no deja de ser enigmática, llena de topicazos, en resumen, no se sabe muy bien de que va nuestro trabajo y los problemas que tenemos.
- participación de un programador
- Respuestas a los anteriores post
Es de agradecer, pero hay que decir que esta serie de post no dejaron de ser una reflexiones en voz alta y en una época en la que el autor del blog estaba experimentando.
Esto me hace pensar algunas cosas. Cuando yo hablo con mi madre, sin apenas formación técnica, ella sabe o tiene idea de lo que hace un arquitecto, un albañil, un alicatador, fontanero, electricista. Sabe quien es más cualificado, quien cobra más y quien menos, etc... sin embargo un día la pregunté que si sabía a lo que me dedicaba. No lo sabía, pero es que tampoco sabía muy bien qué hacía un ingeniero de telecomunicación ni un ingeniero informático. Falta formación en ese aspecto y lo que me preocupa es que no solo a mi madre, que no es dueña de ninguna empresa (aunque es una buena gestora :), si no a gente que demuestran su buen hacer en internet y que debería saber tratar y conocer a un equipo técnico. Pero es que hay muchos otros indicadores, por ejemplo, no tener un convenio laboral adaptado y razonable (que daría para un post aparte), la poca, poquísima estima social, la inconprensible forma de trabajar, etc, etc.
En mi corta, pero intensa, trayectoria profesional, NUNCA un inversor ha venido a conocerme a ver como trabaja el equipo técnico. Ya no hablo de una auditoría técnica, hablo de ver si el equipo está motivado, si tienen gusto por el trabajo, en resumen, ver a las personas, a las que por ahora llaman RECURSOS (qué poca sensibilidad y que falta de respeto).
Es cuestión de tiempo, que tendrá que pasar hasta que la gente del sector y la sociedad se vaya dando cuenta y adquiera un poco de sentido común tecnológico.
A ver cuantos me vienen ahora diciendo que lo que hago yo en España, lo hacen en Rumanía por un cuarto de lo que cobro yo. Y además trabajan el triple, se quejan menos y hacen las cosas más rápido. Total, somos unos obreritos (no obreros, con todo el respeto hacia mis compañeros del metal).
Pero hay una cosa que me mata y me molesta profundamente, y es la poca consideración, atención, protagonismo, llámalo como quieras, que dan a las personas de la parte técnica, a la producción real del producto. Casi siempre los elogios, comentarios positivos son a los que han puesto el dinero, los que han dirigido el desarrollo, los que han vendido, etc, a los que no quito mérito, pero es que al igual que sin ellos no habría nada, sin nosotros los técnicos, tampoco lo habría. Somos los productores de la materia prima, ¿por qué siempre los primeros de la cadena somos los peor considerados?.
Pongamos un ejemplo, hace poco se presentaba yes.fm, del cual Alejando Suárez es socio fundador, y no hace demasiado tiempo enumeraba al equipo de yes.fm. Bien, ni un solo técnico, mínimo creo yo, una reseña al director técnico o similar. Se lo recriminé en un comentario, al cual me respondió que haría un post sobre ello, el cual aún estoy esperando, y no soy el único (lee los comentarios del post). Admito que se lo han currando mucho en cuanto a la parte de marketing, etc, tiene pinta de ser algo bueno, pero es que creo que es un proyecto técnicamente también muy ambiciosos, digno de reseña.
Cierto es que hay pequeñas reseñas, por ejemplo Rodolfo hizo un par de post este verano, en los cuales participé sobre el tema de los programadores y técnicos varios:
- hablando de programadores. En este post se demuestra que la visión de un técnico no deja de ser enigmática, llena de topicazos, en resumen, no se sabe muy bien de que va nuestro trabajo y los problemas que tenemos.
- participación de un programador
- Respuestas a los anteriores post
Es de agradecer, pero hay que decir que esta serie de post no dejaron de ser una reflexiones en voz alta y en una época en la que el autor del blog estaba experimentando.
Esto me hace pensar algunas cosas. Cuando yo hablo con mi madre, sin apenas formación técnica, ella sabe o tiene idea de lo que hace un arquitecto, un albañil, un alicatador, fontanero, electricista. Sabe quien es más cualificado, quien cobra más y quien menos, etc... sin embargo un día la pregunté que si sabía a lo que me dedicaba. No lo sabía, pero es que tampoco sabía muy bien qué hacía un ingeniero de telecomunicación ni un ingeniero informático. Falta formación en ese aspecto y lo que me preocupa es que no solo a mi madre, que no es dueña de ninguna empresa (aunque es una buena gestora :), si no a gente que demuestran su buen hacer en internet y que debería saber tratar y conocer a un equipo técnico. Pero es que hay muchos otros indicadores, por ejemplo, no tener un convenio laboral adaptado y razonable (que daría para un post aparte), la poca, poquísima estima social, la inconprensible forma de trabajar, etc, etc.
En mi corta, pero intensa, trayectoria profesional, NUNCA un inversor ha venido a conocerme a ver como trabaja el equipo técnico. Ya no hablo de una auditoría técnica, hablo de ver si el equipo está motivado, si tienen gusto por el trabajo, en resumen, ver a las personas, a las que por ahora llaman RECURSOS (qué poca sensibilidad y que falta de respeto).
Es cuestión de tiempo, que tendrá que pasar hasta que la gente del sector y la sociedad se vaya dando cuenta y adquiera un poco de sentido común tecnológico.
A ver cuantos me vienen ahora diciendo que lo que hago yo en España, lo hacen en Rumanía por un cuarto de lo que cobro yo. Y además trabajan el triple, se quejan menos y hacen las cosas más rápido. Total, somos unos obreritos (no obreros, con todo el respeto hacia mis compañeros del metal).
Etiquetas:
cultura informatica,
programacion
9.10.2008
dos años de agroguía
Parece que fue ayer cuando la primera persona nos llamó para interesarse por agroguía y ya han pasado dos años. Quien nos iba a decir que esos carteles que pusimos tímidamente iban a captar la atención de alguien...
Para el que no esté al tanto, agroguía es un sistema de guiado GPS para la agricultura, esto es, permite al agricultor en todo momento que zonas ha tratado y cuales no. Parece de perogrullo, pero no es fácil saber por donde has pasado en un terreno con una superfie considerable o mantener una distancia constante a una línea imaginaria.
Ya he escrito bastante acerca de como nos han ido las cosas, los problemas que hemos tenido, anecdotas, casi siempre visto desde el punto de vista de un desarrollador. La verdad que estoy satisfecho, creo que todo ha salido muy bien, pero sobretodo me gusta la idea de que todo lo hemos hecho nosotros: la aplicación, la comercialización, el soporte - que importante es que el desarrollador de soporte al cliente - , al web, la forma de hacer las cosas. Seguramente las hayamos hecho ni medio bien, la gente nos ha criticado hasta la saciedad por no acceder a que lo comercialicen terceros, he llegado hasta a recibir descalificaciones personales, quizas _un poco_ motivada por mi opinión del sector "comercial" (ojo, entrecomillado, nadie se ofenda).
En resumen:
- hemos estado en ferias
- Nos han publicado artículos en varias revistas, que recuerde, además en mapping, tierras y alguna que otra publicación más. La mayor parte de la culpa la tiene Jaime Gómez.
- Hemos visto cosas curiosas, por ejemplo el agricultor que nos preguntó que donde se compraba el líquido naranja, alguna que otra foto, agricultores 2.0.
- Ya hemos llegado al break event ... jaja
- Podemos decir que facturamos, hacienda nos roba lo mismo que a todo el mundo y ahora ya comprendemos a la gente que anda buscando facturas como locos. Puedo afirmar que el negocio da para vivir bien 3 personas, a pesar de los impuestos. Y eso, aunque suene mal lo que voy a escribir, sin lamerle el culo a nadie, aunque eso sí, con ayuda de mucha buena gente.
- Personalmente me ha permitido durante este tiempo poder hacer lo que realmente me ha dado la gana. He programado cuando he querido, he investigado, he hecho las pruebas que he querido. Este es quizás el punto más importante para mi y que precisamente estoy empezando a valorar en su justa medida. Incluso las características que he implementado por puro placer han gustado mucho, en contra de mi pronóstico, y venden.
Se aproxima la tercera temporada y por lo que veo viene muy muy bien. Este año ha habido muy buena cosecha, ha subido el precio de la materia prima y los agricultores no han notado demasiado la subida del carburante (la notarán este periodo). Aún no tienes tu GPS agricola (perdonad, pero google se tiene que enterar también)
Para el que no esté al tanto, agroguía es un sistema de guiado GPS para la agricultura, esto es, permite al agricultor en todo momento que zonas ha tratado y cuales no. Parece de perogrullo, pero no es fácil saber por donde has pasado en un terreno con una superfie considerable o mantener una distancia constante a una línea imaginaria.
Ya he escrito bastante acerca de como nos han ido las cosas, los problemas que hemos tenido, anecdotas, casi siempre visto desde el punto de vista de un desarrollador. La verdad que estoy satisfecho, creo que todo ha salido muy bien, pero sobretodo me gusta la idea de que todo lo hemos hecho nosotros: la aplicación, la comercialización, el soporte - que importante es que el desarrollador de soporte al cliente - , al web, la forma de hacer las cosas. Seguramente las hayamos hecho ni medio bien, la gente nos ha criticado hasta la saciedad por no acceder a que lo comercialicen terceros, he llegado hasta a recibir descalificaciones personales, quizas _un poco_ motivada por mi opinión del sector "comercial" (ojo, entrecomillado, nadie se ofenda).
En resumen:
- hemos estado en ferias
- Nos han publicado artículos en varias revistas, que recuerde, además en mapping, tierras y alguna que otra publicación más. La mayor parte de la culpa la tiene Jaime Gómez.
- Hemos visto cosas curiosas, por ejemplo el agricultor que nos preguntó que donde se compraba el líquido naranja, alguna que otra foto, agricultores 2.0.
- Ya hemos llegado al break event ... jaja
- Podemos decir que facturamos, hacienda nos roba lo mismo que a todo el mundo y ahora ya comprendemos a la gente que anda buscando facturas como locos. Puedo afirmar que el negocio da para vivir bien 3 personas, a pesar de los impuestos. Y eso, aunque suene mal lo que voy a escribir, sin lamerle el culo a nadie, aunque eso sí, con ayuda de mucha buena gente.
- Personalmente me ha permitido durante este tiempo poder hacer lo que realmente me ha dado la gana. He programado cuando he querido, he investigado, he hecho las pruebas que he querido. Este es quizás el punto más importante para mi y que precisamente estoy empezando a valorar en su justa medida. Incluso las características que he implementado por puro placer han gustado mucho, en contra de mi pronóstico, y venden.
Se aproxima la tercera temporada y por lo que veo viene muy muy bien. Este año ha habido muy buena cosecha, ha subido el precio de la materia prima y los agricultores no han notado demasiado la subida del carburante (la notarán este periodo). Aún no tienes tu GPS agricola (perdonad, pero google se tiene que enterar también)
9.09.2008
mejor poco y bien que mucho y mal
No hace demasiado hacía referencia al libro de 37signals getting real y cada día que pasa creo que estoy más de acuerdo don ellos. Estaba buscando en el índice del libro un capítulo que ilustrase lo que quiero decir, pero es que creo que todo el libro ilustra lo que quiero decir. Quizás el que mejor lo tiene es "Get something real up and running quickly", esto es, haz algo que funcione.
Cada día que pasa estoy más convencido que el software _necesita_ un proceso de maduración. Mi abuelo hace vino y se tira todo el santo año cuidando el majuelo, poda las parras, las alumbra (1), las injerta (2), ara el majuelo con un arado especial (menos ancho de lo normal), va a menudo a ver que tal va, pone sistemas para que los pájaros con se coman las uvas (por ejemplo los típicos CD's), se pelea con el vecino para que no ponga panales de abejas, lo protege de los paseantes que quieren comerse las uvas cuando esté madura... luego lo vendimia, lo lleva al lagar (3) o la prensa, primero pisa la uva (de ahí sale el mosto más dulce), luego la prensa y mete en los cubetos. Tras varios meses en el que el mosto fermenta y se convierte en vino mi abuelo está pendiente de que nadie entre en la bodega ya que se puede afixiar (el proceso de creación del alcohol es así) ¡¡el vino ya se puede tomar!!
Sin embargo, a pesar de haber trabajado mucho, mi abuelo no queda conforme con su vino, sabe que debe meterlo en botellas de cristal, ponerle unos buenos corchos, etiquetarlas convenientemente (hasta mi abuelo lleva trazabilidad) y esperar laaargos años hasta poder tener un buen vino, el vino por el que todos te felicitan y recuerdan. A veces el corcho no está bien y se pica el vino o resulta que la cosecha no tuvo suficienta azúcar y el vino salió un poco flojo.
Exactamente pasa igual con un producto software, primero se crea y luego se madura. La diferencia es que la madurez del producto se adquiere una vez lo vas dando a probar. Por eso cuanto antes lo des a probar, mejor, y además cuanto menos des a probar, mejor que mejor.
De nada sirve estar un año creando un software con muchos matices si luego, a la hora de la verdad, no funciona muy bien la parte principal. Hace no demasiado presentaban google chrome, todo el mundo ha comentado lo bien que funciona y a pesar de que muchos han echado en falta la posibilidad de incluir pluggins, entre otros, hay buen sabor de boca, incluso se ha destacado su minimalismo.
Como desarrollador tiene también sus ventajas, sientes que has hecho algo redondo, que funciona y que es completamente usable. No hay peor sensación que la de estar frente a un sistema mastodóntico, que no sabes muy bien como funciona y que "a veces" (cuando pasa esto siempre se asocia a un fallo de sincronización de hilos) no "tira" como debería. Poner a funcionar un sistema simple es ya de por sí difícil, así que no me quiero imaginar si además el propio sistema te pone la zancadilla.
Lo mejor es que todo esto lo puedes aplicar a cada clase/fichero/subsistema :).
(1) alumbrar es hacer un hueco debajo de la planta para que el agua se acumule allí.
(2) hacer una especie de lego con las plantas, se deja la raiz de una y se acuña otro tipo de planta sobre ella, es realmente curioso, algo así como un frankestein.
(3) lugar donde se pisa la uva
Cada día que pasa estoy más convencido que el software _necesita_ un proceso de maduración. Mi abuelo hace vino y se tira todo el santo año cuidando el majuelo, poda las parras, las alumbra (1), las injerta (2), ara el majuelo con un arado especial (menos ancho de lo normal), va a menudo a ver que tal va, pone sistemas para que los pájaros con se coman las uvas (por ejemplo los típicos CD's), se pelea con el vecino para que no ponga panales de abejas, lo protege de los paseantes que quieren comerse las uvas cuando esté madura... luego lo vendimia, lo lleva al lagar (3) o la prensa, primero pisa la uva (de ahí sale el mosto más dulce), luego la prensa y mete en los cubetos. Tras varios meses en el que el mosto fermenta y se convierte en vino mi abuelo está pendiente de que nadie entre en la bodega ya que se puede afixiar (el proceso de creación del alcohol es así) ¡¡el vino ya se puede tomar!!
Sin embargo, a pesar de haber trabajado mucho, mi abuelo no queda conforme con su vino, sabe que debe meterlo en botellas de cristal, ponerle unos buenos corchos, etiquetarlas convenientemente (hasta mi abuelo lleva trazabilidad) y esperar laaargos años hasta poder tener un buen vino, el vino por el que todos te felicitan y recuerdan. A veces el corcho no está bien y se pica el vino o resulta que la cosecha no tuvo suficienta azúcar y el vino salió un poco flojo.
Exactamente pasa igual con un producto software, primero se crea y luego se madura. La diferencia es que la madurez del producto se adquiere una vez lo vas dando a probar. Por eso cuanto antes lo des a probar, mejor, y además cuanto menos des a probar, mejor que mejor.
De nada sirve estar un año creando un software con muchos matices si luego, a la hora de la verdad, no funciona muy bien la parte principal. Hace no demasiado presentaban google chrome, todo el mundo ha comentado lo bien que funciona y a pesar de que muchos han echado en falta la posibilidad de incluir pluggins, entre otros, hay buen sabor de boca, incluso se ha destacado su minimalismo.
Como desarrollador tiene también sus ventajas, sientes que has hecho algo redondo, que funciona y que es completamente usable. No hay peor sensación que la de estar frente a un sistema mastodóntico, que no sabes muy bien como funciona y que "a veces" (cuando pasa esto siempre se asocia a un fallo de sincronización de hilos) no "tira" como debería. Poner a funcionar un sistema simple es ya de por sí difícil, así que no me quiero imaginar si además el propio sistema te pone la zancadilla.
Lo mejor es que todo esto lo puedes aplicar a cada clase/fichero/subsistema :).
(1) alumbrar es hacer un hueco debajo de la planta para que el agua se acumule allí.
(2) hacer una especie de lego con las plantas, se deja la raiz de una y se acuña otro tipo de planta sobre ella, es realmente curioso, algo así como un frankestein.
(3) lugar donde se pisa la uva
Suscribirse a:
Entradas (Atom)