Re: Java vs .Net
Pienso que para ser un buen programador no hay que solo conocer un lenguaje o plataforma, hay que saber de frameworks, vms y sobre todo de metodología, patrones de diseño/iteración, buenas practicas, etc., cosas que le permitan al desarrollador crear una aplicación decente, escalable y robusta. No todo tiene que ver con el lenguaje y el manejo que se tenga de este. En cuanto a lo que me decía Daniel, nadie esta siempre 100% de acuerdo con algo, yo soy Java fan boy, pero por lo que me han contado y he visto .Net no tiene nada que envidiar a Java y de seguro que tiene ventajas gracias al soporte de MS y es a eso a lo que quiero apuntar, para que no nos desviemos del tema central, solo he leído un par de respuestas que están centradas en el thread. Saludos. Cordialmente, Javier Garay G. Ingeniero en Informática. El 13-06-2012, a las 23:34, Christian Pedreros christian.pedre...@gmail.com escribió: El 13-06-2012 23:20, Daniel Molina Wegener escribió: On 13/06/12 22:14, Felipe wrote: La verdad Javier, estoy en profundo desacuerdo contigo. Me refiero especificamente a la frase: permiten enfocarse de mejor manera en la lógica de negocio del sistema, en lugar de estarse preocupando por el código en si. No estoy de acuerdo al 100% con tus ejemplos, pero si en varios aspectos. Eso viene del mito nacido con Visual Basic 5/6 de que cualquiera puede programar y /este lenguaje/ es la panacea. Creo que no existe mito mas falso... ;) No es tan falso: realmente cualquiera puede programar, como postulan en www.codecademy.com De hecho su curso es bastante amigable con la gente que no sabe nada de programacion. Ahora, lo dificil es que cualquiera haga buenos programas... eso es otro cuento! La verdad, ambos aspectos son importantes, y el desarrollo se vuelve mas colaborativo, escalable y ameno con buenas practicas de desarrollo que son transversales a todos los lenguajes de programacion y stacks tecnologicos. Algunos ejemplos de porque si hay que preocuparse del codigo en si: Ejemplo #1: Tienes un servicio critico en una nube en Windows Azure y de pronto se cae. Tienes 0 segundos para arreglarlo y cada segundo que pasa significa una perdida significativa. Ves los logs, pero no hay nada. Solo hay OLAA AQUI ESTOY PASANDO!! y tonteras similares. Abres Visual Studio, y por no preocuparte del codigo en si, terminas revisando miles de lineas de codigo, donde posiblemente algunas de ellas no estan en uso, y ocupas mucho tiempo en proporcionar una solucion. Para cuando terminas, el downtime total genero nuevos problemas con consecuencias graves para el negocio. Ejemplo #2: Tu jefe contrata mas gente, los hace trabajar contigo, pero por no preocuparte del codigo en si, nadie se siente capaz de agregar nuevas funcionalidades o corregir un defecto. Despues de mucho tiempo invertido, la persona hace un commit y todo se rompe. Ejemplo #3: 2 personas intentan trabajar, pero todo esta en una clase gigante. Elige el desenlace: a) Para evitar hacer un merge gigante, una de las personas se va a tomar un cafe y a leer el diario. La empresa cambia dinero y cafe a cambio de nada. b) Hacen un merge gigante, se demoran 20 minutos y meten un bug nuevo. El log de control de versiones tiene un merge por commit. Ejemplo #4: Quieren agregar pruebas de unidad. Tarde en el desarrollo, como siempre ocurre cuando no te preocupas del codigo en si. Pero como esta todo acoplado. Implementar una prueba a nivel unitario se vuelve imposible y tu prueba se vuelve equivalente a correr el programa completo. Hacer un deployment a produccion se vuelve un juego de azar. La integracion continua se vuelve imposible o pierde sus ventajas. Ejemplo #5: Te llega un reporte de bug. Arreglas la porcion de codigo afectada pero por no reutilizar codigo (pues para que preocuparse del codigo en si), hay codigo que resuelve el mismo problema en secciones distintas del proyecto. De pronto, tienes un bug fix parcial y alargaste el QA una semana. Asi que, en mi opinion, el codigo siempre es importante. No es lo mas importante, y no es lo unico importante, pero es importante. Gracias, Atte.
Re: Java vs .Net
On 13/06/12 23:33, Christian Pedreros wrote: El 13-06-2012 23:20, Daniel Molina Wegener escribió: On 13/06/12 22:14, Felipe wrote: La verdad Javier, estoy en profundo desacuerdo contigo. Me refiero especificamente a la frase: permiten enfocarse de mejor manera en la lógica de negocio del sistema, en lugar de estarse preocupando por el código en si. No estoy de acuerdo al 100% con tus ejemplos, pero si en varios aspectos. Eso viene del mito nacido con Visual Basic 5/6 de que cualquiera puede programar y /este lenguaje/ es la panacea. Creo que no existe mito mas falso... ;) No es tan falso: realmente cualquiera puede programar, como postulan en www.codecademy.com De hecho su curso es bastante amigable con la gente que no sabe nada de programacion. Ahora, lo dificil es que cualquiera haga buenos programas... eso es otro cuento! No creo que sea asi. Te doy el ejemplo del proyecto en el que estoy ahora, disenie un priority queue que es dinamico, cambia de acuerdo a las variables de entorno para un sistema de control industrial en la estacion de procesamiento (donde llegan los datos), me base en una maquina de estados para hacer los cambios en el priority queue, que esta debidamente formalizada en un automata. Ademas de eso el modelo del proceso va a estar debidamente verificado y formalizado en un paper usando algunas herramientas de verificacion (como calculo pi). Programar no es solamente saber que la instruccion print imprime en pantalla, o saber que print escribe en el buffer stdout, etc. Lo tecnico es una cosa, pero sin la base teorica adecuada, se cae en errores y a veces errores graves. Te doy otro ejemplo. Me encargaron mantener un proyecto tipo workflow. El programador anterior no tenia la base teorica respecto a automatas. El codigo que dio por resultado eso fue una selva de instrucciones if muy dificil de mantener. Bastaba con meter los estados del workflow en una maquina para hacerlo mas ordenado. Insisto en que saber programar no es cuestion de solo saber meter instrucciones en un archivo, hay hartas cosas mas... La verdad, ambos aspectos son importantes, y el desarrollo se vuelve mas colaborativo, escalable y ameno con buenas practicas de desarrollo que son transversales a todos los lenguajes de programacion y stacks tecnologicos. Algunos ejemplos de porque si hay que preocuparse del codigo en si: Ejemplo #1: Tienes un servicio critico en una nube en Windows Azure y de pronto se cae. Tienes 0 segundos para arreglarlo y cada segundo que pasa significa una perdida significativa. Ves los logs, pero no hay nada. Solo hay OLAA AQUI ESTOY PASANDO!! y tonteras similares. Abres Visual Studio, y por no preocuparte del codigo en si, terminas revisando miles de lineas de codigo, donde posiblemente algunas de ellas no estan en uso, y ocupas mucho tiempo en proporcionar una solucion. Para cuando terminas, el downtime total genero nuevos problemas con consecuencias graves para el negocio. Ejemplo #2: Tu jefe contrata mas gente, los hace trabajar contigo, pero por no preocuparte del codigo en si, nadie se siente capaz de agregar nuevas funcionalidades o corregir un defecto. Despues de mucho tiempo invertido, la persona hace un commit y todo se rompe. Ejemplo #3: 2 personas intentan trabajar, pero todo esta en una clase gigante. Elige el desenlace: a) Para evitar hacer un merge gigante, una de las personas se va a tomar un cafe y a leer el diario. La empresa cambia dinero y cafe a cambio de nada. b) Hacen un merge gigante, se demoran 20 minutos y meten un bug nuevo. El log de control de versiones tiene un merge por commit. Ejemplo #4: Quieren agregar pruebas de unidad. Tarde en el desarrollo, como siempre ocurre cuando no te preocupas del codigo en si. Pero como esta todo acoplado. Implementar una prueba a nivel unitario se vuelve imposible y tu prueba se vuelve equivalente a correr el programa completo. Hacer un deployment a produccion se vuelve un juego de azar. La integracion continua se vuelve imposible o pierde sus ventajas. Ejemplo #5: Te llega un reporte de bug. Arreglas la porcion de codigo afectada pero por no reutilizar codigo (pues para que preocuparse del codigo en si), hay codigo que resuelve el mismo problema en secciones distintas del proyecto. De pronto, tienes un bug fix parcial y alargaste el QA una semana. Asi que, en mi opinion, el codigo siempre es importante. No es lo mas importante, y no es lo unico importante, pero es importante. Gracias, Atte. Atte. -- Daniel Molina Wegener dmw [at] coder [dot] cl System Programmer Web Developer Phone: +56 (2) 979-0278 | Blog: http://coder.cl/
Re: Java vs .Net
On 14/06/12 02:39, Javier Garay wrote: Pienso que para ser un buen programador no hay que solo conocer un lenguaje o plataforma, hay que saber de frameworks, vms y sobre todo de metodología, patrones de diseño/iteración, buenas practicas, etc., cosas que le permitan al desarrollador crear una aplicación decente, escalable y robusta. No todo tiene que ver con el lenguaje y el manejo que se tenga de este. Los aspectos tecnicos y metodologicos no sirven de nada sin una buena base teorica... En cuanto a lo que me decía Daniel, nadie esta siempre 100% de acuerdo con algo, yo soy Java fan boy, pero por lo que me han contado y he visto .Net no tiene nada que envidiar a Java y de seguro que tiene ventajas gracias al soporte de MS y es a eso a lo que quiero apuntar, para que no nos desviemos del tema central, solo he leído un par de respuestas que están centradas en el thread. En Java en cuanto a productividad tienes Scala, puedes escribir en menos lineas de codigo algo productivo, te doy un ejemplo, si sabes como calcular la varianza, el siguiente codigo en Haskell lo puedes migrar a la misma cantidad de lineas en Scala para calcularla sobre una lista / array de Floats: olVar :: [Float] - Float olVar [] = 0.0 olVar xs = lolVar xs 0 0 0 where lolVar [] n' m' r' = (r' / (n' - 1)) :: Float lolVar (t:ts) n m r = let n' = n + 1.0 d' = t - m m' = m + d' / n' r' = r + d' * (t - m') in lolVar ts n' m' r' Con una sola iteracion (no con 2 iteraciones como lo indica la forma tradicional). Eso si que es productivo. Con todas las ventajas que tiene la JVM y la potencia de un lenguaje 100% multiparadigma como Scala. Saludos. Cordialmente, Javier Garay G. Ingeniero en Informática. El 13-06-2012, a las 23:34, Christian Pedreros christian.pedre...@gmail.com escribió: El 13-06-2012 23:20, Daniel Molina Wegener escribió: On 13/06/12 22:14, Felipe wrote: La verdad Javier, estoy en profundo desacuerdo contigo. Me refiero especificamente a la frase: permiten enfocarse de mejor manera en la lógica de negocio del sistema, en lugar de estarse preocupando por el código en si. No estoy de acuerdo al 100% con tus ejemplos, pero si en varios aspectos. Eso viene del mito nacido con Visual Basic 5/6 de que cualquiera puede programar y /este lenguaje/ es la panacea. Creo que no existe mito mas falso... ;) No es tan falso: realmente cualquiera puede programar, como postulan en www.codecademy.com De hecho su curso es bastante amigable con la gente que no sabe nada de programacion. Ahora, lo dificil es que cualquiera haga buenos programas... eso es otro cuento! La verdad, ambos aspectos son importantes, y el desarrollo se vuelve mas colaborativo, escalable y ameno con buenas practicas de desarrollo que son transversales a todos los lenguajes de programacion y stacks tecnologicos. Algunos ejemplos de porque si hay que preocuparse del codigo en si: Ejemplo #1: Tienes un servicio critico en una nube en Windows Azure y de pronto se cae. Tienes 0 segundos para arreglarlo y cada segundo que pasa significa una perdida significativa. Ves los logs, pero no hay nada. Solo hay OLAA AQUI ESTOY PASANDO!! y tonteras similares. Abres Visual Studio, y por no preocuparte del codigo en si, terminas revisando miles de lineas de codigo, donde posiblemente algunas de ellas no estan en uso, y ocupas mucho tiempo en proporcionar una solucion. Para cuando terminas, el downtime total genero nuevos problemas con consecuencias graves para el negocio. Ejemplo #2: Tu jefe contrata mas gente, los hace trabajar contigo, pero por no preocuparte del codigo en si, nadie se siente capaz de agregar nuevas funcionalidades o corregir un defecto. Despues de mucho tiempo invertido, la persona hace un commit y todo se rompe. Ejemplo #3: 2 personas intentan trabajar, pero todo esta en una clase gigante. Elige el desenlace: a) Para evitar hacer un merge gigante, una de las personas se va a tomar un cafe y a leer el diario. La empresa cambia dinero y cafe a cambio de nada. b) Hacen un merge gigante, se demoran 20 minutos y meten un bug nuevo. El log de control de versiones tiene un merge por commit. Ejemplo #4: Quieren agregar pruebas de unidad. Tarde en el desarrollo, como siempre ocurre cuando no te preocupas del codigo en si. Pero como esta todo acoplado. Implementar una prueba a nivel unitario se vuelve imposible y tu prueba se vuelve equivalente a correr el programa completo. Hacer un deployment a produccion se vuelve un juego de azar. La integracion continua se vuelve imposible o pierde sus ventajas. Ejemplo #5: Te llega un reporte de bug. Arreglas la porcion de codigo afectada pero por no reutilizar codigo (pues para que preocuparse del codigo en si), hay codigo que resuelve el mismo problema en secciones distintas del proyecto. De pronto, tienes un bug fix parcial y alargaste el QA una
ltsp-server error
Hola recien he instalado un servidor ltsp y creado la imagen cliente correctamente, los clientes arrancan por dhcp y me sale la pantalla de inicio de sesion en el cliente, pero cuando introdusco el usuario y la clave me sale un error diciendo: failed to load session 'ubuntu' del lado del servidor encontre estas lineas en los logs: Jun 14 05:56:12 pvs-bxp dhcpd: DHCPDISCOVER from 00:1c:c0:57:7f:d3 via eth1 Jun 14 05:56:12 pvs-bxp dhcpd: DHCPOFFER on 192.168.1.253 to 00:1c:c0:57:7f:d3 via eth1 Jun 14 05:56:12 pvs-bxp dhcpd: DHCPDISCOVER from 00:1c:c0:57:7f:d3 via eth1 Jun 14 05:56:12 pvs-bxp dhcpd: DHCPOFFER on 192.168.1.253 to 00:1c:c0:57:7f:d3 via eth1 Jun 14 05:56:12 pvs-bxp dhcpd: DHCPREQUEST for 192.168.1.253 (192.168.1.1) from 00:1c:c0:57:7f:d3 via eth1 Jun 14 05:56:12 pvs-bxp dhcpd: DHCPACK on 192.168.1.253 to 00:1c:c0:57:7f:d3 via eth1 Jun 14 05:56:12 pvs-bxp nbd_server[1191]: connect from 192.168.1.253, assigned file is /opt/ltsp/images/i386.img Jun 14 05:56:12 pvs-bxp nbd_server[1191]: Can't open authorization file (null) (Bad address). Jun 14 05:56:12 pvs-bxp nbd_server[1191]: Authorized client Jun 14 05:56:12 pvs-bxp nbd_server[30344]: Starting to serve Jun 14 05:56:12 pvs-bxp nbd_server[30344]: Size of exported file/device is 724312064 Jun 14 05:56:13 pvs-bxp nbd_server[1191]: negotiation failed Jun 14 05:56:13 pvs-bxp nbd_server[1191]: Exiting. Jun 14 05:56:20 pvs-bxp ldminfod[30346]: connect from 192.168.1.249 (192.168.1.249) Jun 14 05:56:20 pvs-bxp ldminfod[30347]: connect from 192.168.1.253 (192.168.1.253) Jun 14 05:56:27 pvs-bxp nbd_server[1191]: connect from 192.168.1.249, assigned file is /opt/ltsp/images/i386.img Jun 14 05:56:27 pvs-bxp nbd_server[1191]: Can't open authorization file (null) (Bad address). Jun 14 05:56:27 pvs-bxp nbd_server[1191]: Authorized client Jun 14 05:56:27 pvs-bxp nbd_server[30364]: Starting to serve Jun 14 05:56:27 pvs-bxp nbd_server[30364]: Size of exported file/device is 724312064 Jun 14 05:56:27 pvs-bxp nbd_server[1191]: connect from 192.168.1.253, assigned file is /opt/ltsp/images/i386.img Jun 14 05:56:27 pvs-bxp nbd_server[1191]: Can't open authorization file (null) (Bad address). Jun 14 05:56:27 pvs-bxp nbd_server[1191]: Authorized client Jun 14 05:56:27 pvs-bxp nbd_server[30365]: Starting to serve Jun 14 05:56:27 pvs-bxp nbd_server[30365]: Size of exported file/device is 724312064 Jun 14 05:56:27 pvs-bxp nbd_server[30365]: Disconnect request received. Jun 14 05:56:27 pvs-bxp nbd_server[1191]: Child exited with 0 Jun 14 05:56:27 pvs-bxp nbd_server[30364]: Disconnect request received. Jun 14 05:56:27 pvs-bxp nbd_server[1191]: Child exited with 0 Jun 14 05:56:53 pvs-bxp x-session-manager[30521]: WARNING: Session 'ubuntu' runnable check failed: Exited with code 1 Jun 14 05:56:53 pvs-bxp x-session-manager[30521]: WARNING: Unable to find default provider 'metacity' of required provider 'windowmanager' Jun 14 05:56:53 pvs-bxp x-session-manager[30521]: WARNING: Unable to find default provider 'unity-2d-panel' of required provider 'panel' Jun 14 05:56:53 pvs-bxp x-session-manager[30521]: WARNING: Unable to find default provider 'unity-2d-shell' of required provider 'shell'
