#61 Desde luego. Como he dicho antes, si la arquitectura está bien hecha, modificar la base de una aplicación para mejorar la parte visual no es necesario.
Ahora, en mundos menos ideales, muchos aplicativos se hicieron con los pies hace 20 años, es lo que hay, y hay que seguir manteniéndolos hoy en día con el infierno de capas de cebolla que se han ido creando por gente que tenía miedo de tocar la base y se han dedicado a crear sucesivas capas por encima "para no romper nada". Después de 20 años y 15 desarrolladores, el panorama suele ser desolador. Y cuando planteas tocar algo de la base te dicen "nooooo, loco!".
Cuando en la empresa queda alguien que sabe como funciona la "base", no suele haber problemas. Cuando jubilaron a todos los que había hace 5 años para poner a becarios a mantener un sistema del que no tienen ni idea es cuando empieza la fiesta.
Para que nos entendamos: si la arquitectura es buena, la tecnología es secundaria, y el crecimiento de la aplicación se puede gestionar. Si la arquitectura es mala, crecer durante años encima de ella no suele ser buena idea.
#65 O que cambia el sistema operativo, algún registro cambia de tamaño y el cobol que es tan cuadriculado con los datos pues se ha de "retocar". Y el que parió la aplicación hace diez años que se jubiló y los que venían después no habían ni oído hablar de esa aplicación... simplemente porque nunca había dado problemas. 
Aquí... "apaños martínez"
#59 Bien. Veo que me explico muy mal.
Mi contexto: empresa de desarrollo. Hablo desde el punto de vista de alguien que, diariamente, tiene que modificar un software, por incidencias o por mejoras. En ese contexto, la frase "si funciona no lo toques", tal y como he dicho en #25 y desarrollado en #36, en mi experiencia, pocas veces se aplica por cuestiones técnicas y es discutible.
Desde luego si me planteas la opción de #45, donde no hay nada que arreglar ni que mejorar, ni se plantea la cuestión. Y, en casos como ha detallado #32, puede que no aporte nada una nueva tecnología o un nuevo enfoque.
Por tanto, sí, mi frase en #25 generaliza, igual que la de #10, luego él puntualiza, y yo también, y todos somos felices (al menos yo, porque básicamente estoy de acuerdo con él).
#62 SE me olvidó un al final de mi comentario... igual así se entiende mejor.
En realidad estoy de acuerdo. "si funciona no lo toques".... si se trabaja con herramientas obsoletas que impidean realizar cambios, no te dan la funcionalidad que necesitas, o todo ello es muy ineficiente por carecer de personal que domine dichas herramientas... pues esta claro, lo que tienes no funciona, hay que cambiarlo.
#45 Creo que has obviado una parte importante de la argumentación: "en aquellos sistemas en los que se desarrolla a diario".
Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada.
#49 Aquí dices que: "Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada."
Y a la vez, en #10 , todo lo contrario: "Filosofía que básicamente mata de raíz todo intento de mejora en muchas empresas. No romperás casi nada, eso sí. Solo te quedarás estancado."
#59 Bien. Veo que me explico muy mal.
Mi contexto: empresa de desarrollo. Hablo desde el punto de vista de alguien que, diariamente, tiene que modificar un software, por incidencias o por mejoras. En ese contexto, la frase "si funciona no lo toques", tal y como he dicho en #25 y desarrollado en #36, en mi experiencia, pocas veces se aplica por cuestiones técnicas y es discutible.
Desde luego si me planteas la opción de #45, donde no hay nada que arreglar ni que mejorar, ni se plantea la cuestión. Y, en casos como ha detallado #32, puede que no aporte nada una nueva tecnología o un nuevo enfoque.
Por tanto, sí, mi frase en #25 generaliza, igual que la de #10, luego él puntualiza, y yo también, y todos somos felices (al menos yo, porque básicamente estoy de acuerdo con él).
#62 SE me olvidó un al final de mi comentario... igual así se entiende mejor.
En realidad estoy de acuerdo. "si funciona no lo toques".... si se trabaja con herramientas obsoletas que impidean realizar cambios, no te dan la funcionalidad que necesitas, o todo ello es muy ineficiente por carecer de personal que domine dichas herramientas... pues esta claro, lo que tienes no funciona, hay que cambiarlo.
#32 Está claro que depende totalmente del proyecto. Pero en aquellos sistemas en los que se desarrolla a diario, las nuevas tecnologías sí te permiten muchas veces eliminar barreras de acceso a nuevos programadores, y facilitar el desarrollo. Y en mi experiencia (que no es en esos ámbitos que comentas), los que te suelen decir eso suelen ser los que no tienen mucha idea y sí mucho miedo de tocar algo que no controlan (o de que les vayas a dejar mal).
En todo caso creo que si la arquitectura está bien hecha, siempre habrá maneras de integrar "nuevas tecnologías" en aquellos apartados en los que aportarán valor (por ejemplo interfaz visual), dejando el "core" de la aplicación en modo "no toques".
El contexto determina la validez de la premisa.
#36 Conozco una pequeña empresa de venta de componentes electrónicos.
Les hicieron una aplicación en Cobol en los años 80 que funcionaba como un reloj.
A día de hoy la siguen utilizando para la gestión diaria de todo el stock.
Obviamente la aplicación corre en un sistema Novell Virtualizado.
El dueño de la empresa dice que el software funciona perfectamente, costó una pequeña fortuna y hace bien su trabajo.
¿Para qué cambiarlo?
#45 Creo que has obviado una parte importante de la argumentación: "en aquellos sistemas en los que se desarrolla a diario".
Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada.
#49 Aquí dices que: "Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada."
Y a la vez, en #10 , todo lo contrario: "Filosofía que básicamente mata de raíz todo intento de mejora en muchas empresas. No romperás casi nada, eso sí. Solo te quedarás estancado."
#59 Bien. Veo que me explico muy mal.
Mi contexto: empresa de desarrollo. Hablo desde el punto de vista de alguien que, diariamente, tiene que modificar un software, por incidencias o por mejoras. En ese contexto, la frase "si funciona no lo toques", tal y como he dicho en #25 y desarrollado en #36, en mi experiencia, pocas veces se aplica por cuestiones técnicas y es discutible.
Desde luego si me planteas la opción de #45, donde no hay nada que arreglar ni que mejorar, ni se plantea la cuestión. Y, en casos como ha detallado #32, puede que no aporte nada una nueva tecnología o un nuevo enfoque.
Por tanto, sí, mi frase en #25 generaliza, igual que la de #10, luego él puntualiza, y yo también, y todos somos felices (al menos yo, porque básicamente estoy de acuerdo con él).
#62 SE me olvidó un al final de mi comentario... igual así se entiende mejor.
En realidad estoy de acuerdo. "si funciona no lo toques".... si se trabaja con herramientas obsoletas que impidean realizar cambios, no te dan la funcionalidad que necesitas, o todo ello es muy ineficiente por carecer de personal que domine dichas herramientas... pues esta claro, lo que tienes no funciona, hay que cambiarlo.
#45 Esa empresa no estará por casualidad en Valencia? Si no es así, conozco otra con el mismo caso
#72 No es en Madrid, se llama "Digital".
http://www.digital-sa.com/tienda/
#36 Tu hablas de interfaces, lo que yo llamo "maquillaje". He visto sistemas cuyo interface es totalmente "moderno" (graficos, interfaz http y colorines) y cuya base son aplicativos de hace 30 años que funcionan como relojes. De hecho, esa carcasa (desarrollada a posteriori) se ha jodido algunas veces, y todo es llanto y crujir de dientes, mientras que el sistema base sigue funcionando de modo genial accesible por transacciones en modo directo (emulacion 3270). Pero claro, no pidas a determinados usuarios que sepan usar un CICS en nativo.
#61 Desde luego. Como he dicho antes, si la arquitectura está bien hecha, modificar la base de una aplicación para mejorar la parte visual no es necesario.
Ahora, en mundos menos ideales, muchos aplicativos se hicieron con los pies hace 20 años, es lo que hay, y hay que seguir manteniéndolos hoy en día con el infierno de capas de cebolla que se han ido creando por gente que tenía miedo de tocar la base y se han dedicado a crear sucesivas capas por encima "para no romper nada". Después de 20 años y 15 desarrolladores, el panorama suele ser desolador. Y cuando planteas tocar algo de la base te dicen "nooooo, loco!".
Cuando en la empresa queda alguien que sabe como funciona la "base", no suele haber problemas. Cuando jubilaron a todos los que había hace 5 años para poner a becarios a mantener un sistema del que no tienen ni idea es cuando empieza la fiesta.
Para que nos entendamos: si la arquitectura es buena, la tecnología es secundaria, y el crecimiento de la aplicación se puede gestionar. Si la arquitectura es mala, crecer durante años encima de ella no suele ser buena idea.
#65 O que cambia el sistema operativo, algún registro cambia de tamaño y el cobol que es tan cuadriculado con los datos pues se ha de "retocar". Y el que parió la aplicación hace diez años que se jubiló y los que venían después no habían ni oído hablar de esa aplicación... simplemente porque nunca había dado problemas. Aquí... "apaños martínez"
#10 Filosofía que básicamente mata de raíz todo intento de mejora en muchas empresas. No romperás casi nada, eso sí. Solo te quedarás estancado.
#25 Muchas veces, sin embargo, más nuevo no significa mejor. Sobre todo si hablamos de aplicativos transaccionales de muchísimo volumen (fábricas, bancos).
#32 Está claro que depende totalmente del proyecto. Pero en aquellos sistemas en los que se desarrolla a diario, las nuevas tecnologías sí te permiten muchas veces eliminar barreras de acceso a nuevos programadores, y facilitar el desarrollo. Y en mi experiencia (que no es en esos ámbitos que comentas), los que te suelen decir eso suelen ser los que no tienen mucha idea y sí mucho miedo de tocar algo que no controlan (o de que les vayas a dejar mal).
En todo caso creo que si la arquitectura está bien hecha, siempre habrá maneras de integrar "nuevas tecnologías" en aquellos apartados en los que aportarán valor (por ejemplo interfaz visual), dejando el "core" de la aplicación en modo "no toques".
El contexto determina la validez de la premisa.
#36 Conozco una pequeña empresa de venta de componentes electrónicos.
Les hicieron una aplicación en Cobol en los años 80 que funcionaba como un reloj.
A día de hoy la siguen utilizando para la gestión diaria de todo el stock.
Obviamente la aplicación corre en un sistema Novell Virtualizado.
El dueño de la empresa dice que el software funciona perfectamente, costó una pequeña fortuna y hace bien su trabajo.
¿Para qué cambiarlo?
#45 Creo que has obviado una parte importante de la argumentación: "en aquellos sistemas en los que se desarrolla a diario".
Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada.
#49 Aquí dices que: "Claramente si un sistema funciona, no tiene incidencias, ni necesidad de desarrollo adicional, no toques nada."
Y a la vez, en #10 , todo lo contrario: "Filosofía que básicamente mata de raíz todo intento de mejora en muchas empresas. No romperás casi nada, eso sí. Solo te quedarás estancado."
#59 Bien. Veo que me explico muy mal.
Mi contexto: empresa de desarrollo. Hablo desde el punto de vista de alguien que, diariamente, tiene que modificar un software, por incidencias o por mejoras. En ese contexto, la frase "si funciona no lo toques", tal y como he dicho en #25 y desarrollado en #36, en mi experiencia, pocas veces se aplica por cuestiones técnicas y es discutible.
Desde luego si me planteas la opción de #45, donde no hay nada que arreglar ni que mejorar, ni se plantea la cuestión. Y, en casos como ha detallado #32, puede que no aporte nada una nueva tecnología o un nuevo enfoque.
Por tanto, sí, mi frase en #25 generaliza, igual que la de #10, luego él puntualiza, y yo también, y todos somos felices (al menos yo, porque básicamente estoy de acuerdo con él).
#62 SE me olvidó un al final de mi comentario... igual así se entiende mejor.
En realidad estoy de acuerdo. "si funciona no lo toques".... si se trabaja con herramientas obsoletas que impidean realizar cambios, no te dan la funcionalidad que necesitas, o todo ello es muy ineficiente por carecer de personal que domine dichas herramientas... pues esta claro, lo que tienes no funciona, hay que cambiarlo.
#45 Esa empresa no estará por casualidad en Valencia? Si no es así, conozco otra con el mismo caso
#72 No es en Madrid, se llama "Digital".
http://www.digital-sa.com/tienda/
#36 Tu hablas de interfaces, lo que yo llamo "maquillaje". He visto sistemas cuyo interface es totalmente "moderno" (graficos, interfaz http y colorines) y cuya base son aplicativos de hace 30 años que funcionan como relojes. De hecho, esa carcasa (desarrollada a posteriori) se ha jodido algunas veces, y todo es llanto y crujir de dientes, mientras que el sistema base sigue funcionando de modo genial accesible por transacciones en modo directo (emulacion 3270). Pero claro, no pidas a determinados usuarios que sepan usar un CICS en nativo.
#61 Desde luego. Como he dicho antes, si la arquitectura está bien hecha, modificar la base de una aplicación para mejorar la parte visual no es necesario.
Ahora, en mundos menos ideales, muchos aplicativos se hicieron con los pies hace 20 años, es lo que hay, y hay que seguir manteniéndolos hoy en día con el infierno de capas de cebolla que se han ido creando por gente que tenía miedo de tocar la base y se han dedicado a crear sucesivas capas por encima "para no romper nada". Después de 20 años y 15 desarrolladores, el panorama suele ser desolador. Y cuando planteas tocar algo de la base te dicen "nooooo, loco!".
Cuando en la empresa queda alguien que sabe como funciona la "base", no suele haber problemas. Cuando jubilaron a todos los que había hace 5 años para poner a becarios a mantener un sistema del que no tienen ni idea es cuando empieza la fiesta.
Para que nos entendamos: si la arquitectura es buena, la tecnología es secundaria, y el crecimiento de la aplicación se puede gestionar. Si la arquitectura es mala, crecer durante años encima de ella no suele ser buena idea.
#65 O que cambia el sistema operativo, algún registro cambia de tamaño y el cobol que es tan cuadriculado con los datos pues se ha de "retocar". Y el que parió la aplicación hace diez años que se jubiló y los que venían después no habían ni oído hablar de esa aplicación... simplemente porque nunca había dado problemas. Aquí... "apaños martínez"
#19 "La culpa es del Islam maluno" bee beeeee
Todas las afirmacions simplistas son igual de lamentables.
#16 ¿Y las empresas no tienen empleados que usan iPad / iPhone / Android con aplicaciones y datos sensibles? Siempre me ha llamado la atención el número de noticias sobre la recopilación de datos en Windows mientras la mayoría la gente se pasea alegremente todo el día con un móvil con el GPS activado. Estoy seguro que Google sabe mucho más de mi, donde voy, con qué amigos, etc. que Microsoft.
Por otro lado las métricas de uso me parecen de lo más normal, lo hacemos nosotros con nuestras aplicaciones para saber qué usan y qué no usan nuestros usuarios. Y las hay que directamente graban *toda la interacción* del usuario en tu página web (¿hotjar anyone?), que me parece bastante brutal también (y es muy fácil de configurar). Eso sí, es más importante avisar de lo de las cookies .
En todo caso una empresa que se preocupa de sus datos lo tiene muy jodido porque la mayoría de software privativo viene de EEUU, y si te pones alarmista nadie te dice que no tienen backdoors convenientemente preparadas. Pero imagino que a Microsoft siempre se le juzgará peor que otras por [inserte razón x aquí].
#22 Yo no tengo el GPS activado en el smartphone, no tengo Facebook y whatasapp en el móvil ni entro en Menéame desde él. Creo que MS sabe más de mi que Google. MS Puede ver que usuario tengo en Menéame, cuales son mis cuentas de correo electrónico y puede almacenar que IP tengo cada vez que enciendo el PC.
#22 Pero sigue dependiendo de quién use el teléfono, con que apps y con que cuentas. Si yo uso el móvil de la empresa con una cuenta blablabla@gmail.com y solo la uso para la empresa, todos los datos que recopile no van a ningún lado (porque solo la uso para el teléfono y nada más). Y los datos que recopilen las apps depende de los permisos que las des, supongo que muchas empresas tienen tanto interés en la privacidad como una mayoría de usuarios.
Pues a mi lo de las métricas (como cualquier tipo de tracking) no me parece normal, tener una app usando los datos de tu móvil simplemente para saber que la estás usando... Lo de la web me parece brutal en muchos aspectos, en mi web implementé de pruebas un proyecto beta que te permitía ver exactamente la pantalla que veía el usuario, dónde movía el ratón, en que clickaba, monitorización total... A mi me horrorizó, lo tuve un día. Javascript + html + cookies (y las variantes como supercookies, almacenamientos, etc.) + php => bomba brutal de espiar. La ley de cookies solo demostró la ignorancia de los eurodiputados ante lo que significa internet.
Una empresa que se preocupe a nivel paranoico con la privacidad usaría Nokias 3210, PCs desconectados de internet y software libre auditado. Osea, casi ninguna, un ambiente de privacidad normal requiere ingentes cantidades de pasta, o tener un firewall hardware bloqueando todo y solo dejando salir tráfico muy determinado. Hasta las empresas más cerradas tienen filtraciones, este es un mal siglo para los preocupados por la privacidad.
#6 Trabajando justamente en una empresa de software que ofrece un producto para hoteles, te recomiendo que siempre consultes la web oficial del hotel por si acaso. No es fácil, porque normalmente Booking y similares te obligan por contrato a darles el precio más bajo, pero por ejemplo se ofrece muchas veces hasta el 10% de descuento por registrarte por la web. Es lo que intentamos hacer, y muchas veces así se consigue un precio más bajo por la web. Y siempre se intentan ofrecer servicios extras para las reservas directas, tipo wifi gratis, regalo de bienvenida, parking o similares.
Contra lo que muy difícilmente se puede luchar es con el precio de paquete vuelo + hotel pactado con tour operadores, en el que el precio de la habitación queda tirado de precio por haber comprado las garantías a principio de año a precio de saldo.
Como bien dice #22, hace más de 20 años que se sabe uno se imagina que Cursach es (presuntamente claro) un mafias, pero es lo que tiene tener amiguetes a todos los niveles, que nadie te busca las cosquillas demasiado.
Lo que me hace gracia es que cada día siguen sonando anuncios (en la SER nada menos) acabados en "con la garantía de Cursach Ocio". La pela es la pela oye.
#22 #25 Y lo que no va a salir... sospechas de asesinatos y desapariciones también hay, o la corrupción de menores que comenta #11. Aquí en Calvià está metido hasta el cuello de mierda todo el mundo, desde los Locales hasta el alcalde pasando por el resto de cuerpos de seguridad, empresarios, hoteleros y políticos.
Bash.org, mejor recopilación de perlas del IRC
bash.orgQuién no ha tenido conversaciones absurdas por IRC ( o similares )? Hace tiempo que Bash.org va recopilando esas "perlas" en su página, clasificándolas según los votos de los usuarios, y realmente algunas valen su peso en oro. En inglés. ( ya sé que Bash.org es una institución para algunos, y que no es ninguna novedad, pero creo que es relativamente poco conocida en España ).
Un ultraligero, una cámara y una gran idea
video.google.comHas querido experimentar la sensación de volar, pero no tienes licencia? Con medios relativamente sencillos y buenas ideas, se pueden hacer cosas como ésta. A mi desde luego me gustaría probarlo.
Dimite el director general de Urbanismo de Madrid
elpais.esEl director general de Urbanismo de la Comunidad de Madrid, Enrique Porto, ha presentado hoy su dimisión. Porto se hallaba en vuelto en un gran escándalo después de que se revelara que aprobó proyectos en los que había participado como urbanista privado antes de asumir el cargo.
Después de Symantec, McAfee también critica Vista
arstechnica.comDespués de Adobe y Symantec, le toca a McAfee quejarse del "cierre de acceso al núcleo" de Windows Vista. En efecto, por primera vez, los programas de seguridad no podrán acceder al núcleo de Windows para ejecutar ciertas tareas con Vista. El núcleo del nuevo sistema operativo de Microsoft utilizará una tecnología de cifrado para mejorar su nivel de seguridad, lo cual no acaba de ser del agrado de las firmas de antivirus, que dicen que serán menos eficientes. Preocupación legítima, o más bien miedo de perder partes de mercado? En inglés.
Explicación y especificaciones del Wizard de Vista, por uno de sus creadores
shellrevealed.comCompleto e interesante overview de lo que será el "Wizard" del próximo sistema operativo de Microsoft. Al final del artículo propone las especificaciones, aunque se necesite IE o Word para verlo ( es un archivo MHT ). En inglés.
#4 Pues los artículos de deportes me parecen de lo mejor que hay, sobretodo comparando con el nivel medio del periodismo deportivo español.