#7:
#c-4" class="content-link" style="color: rgb(, , )" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment//order/4">#4 Poco has programado tú. Normalmente un programa con metodologías modernas y tecnologías actuales tiene que coexistir con programas anteriores de la misma empresa o del antiguo proveedor de servicios del cliente. Esto provoca que haya que hacer mil pirulas para comunicar unas aplicaciones/funcionalidades con otras.
Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón, pero la realidad es que las empresas no tienen tantos recursos como para dedicar media plantilla a seguir dando soporte a la aplicación vieja mientras otra media plantilla desarrolla la nueva. Las cosas se van haciendo poco a poco, cuando el cliente aprieta, e integrando lo nuevo con lo que ya hay.
Te voy a poner un ejemplo de la multinacional en la que trabajo. Tenían una aplicación de escritorio, que migró a internet (html 2), que luego fue reconvertida a otra tecnología web que quedó obsoleta, y luego pasó a html5. Eso convive con otros servicios que automatizan tareas, fuera de la aplicación manejada por el cliente. En total, coexisten aplicaciones en javascript, html, asp, c#, c++, c++ builder, visual c, oracle, sqlite, office y alguna más que se me escapa. Todo en un delicado equilibrio.
#5:
#3 Es tan sencillo como decir "no tengo ni idea, cuando en la empresa tengo un problema, llamo a sistemas". Con esa respuesta, llevo más de 10 años sin arreglar un ordenador que no sea mio.
#10:
#8 Yo no he dicho que sea un caos. Lo que digo es que la aserción 1 tiene razón:
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Que hay un todo que funciona gracias a un montón de ñapas que conectan unas partes con otras. Que es como viajar en un 747 y darte cuenta de que el tubo de la gasolina está sujeto con una percha y que la rueda de aterrizaje está pegada con cinta americana.
#39:
#3, 3 buenos trucos para evitar esas reparaciones:
1) Decir "Traemelo a casa y lo miro": El 90% de las personas no querrá hacerlo por pura vagancia. Si piden un favor y no son capaces de llevarte el bicho, no son merecedores de ninguna ayuda.
2) Decir que eres usuario de linux desde hay 10 años y que no conoces windows lo suficiente.
3) Hacerlo con la condición de que se vista de gallina y te haga una paella.
#68:
#7Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón,
En mi experiencia los que dicen eso son nuevos programadores con muy poca experiencia.
Dile tú a un banco que estaría bien quitar código COBOL que lleva funcionando 40 años, que será muy feo y lo que quieras pero que funciona como un reloj y que lo vas a cambiar por otra cosa que te vas a picar de cero usando la novedad de la semana.
Por cierto, otra verdad que los programadores con experiencia saben: Nuestro propio código revisado 10 años después nos suele parecer una puta mierda.
#109:
#3#5#6#39 Yo fui técnico de sistemas cuando empece a trabajar a los 17 y, si, sabia arreglar ordenadores. La frase que mejor me iba era "Ah, vale, cuando te vaya bien me paso por tu casa. Te haré buen precio".
Manita de santo, nunca me volvían a llamar.
#13:
#11#10 ¡Pelea de gatas!. Cuando veo flames de estos siempre pienso que antes de discutir con alguien (en un campo en que ambos somos entendido en la materia) debemos conocer muy a fondo el bagaje del adversario, porque es muy importante no caer en la trampa de subestimar los conocimientos del oponente. Siempre digo que hay tres tipos de profesionales, los que saben, los que no, y los que "creen" que saben. Considerándome de los segundos, claro.
Dicho esto, soy de la opinión de que el punto 1 tiene más razón que un santo.
#96:
#22#24#28#32#42#45 Supongo que ya lo sabéis, pero el que los arreglos comiencen por 0 no es ningún capricho de algún programador que lo decidió así porque le salió de los cojones. Viene de los lenguajes que tratan al arreglo como posiciones contiguas en memoria. El caso más común es el de C: cuando creas un arreglo en C, lo que obtienes es la posición en memoria del primer elemento, es decir, puntero+0 (puntero es la posición del arreglo en memoria). Para recorrer el resto del arreglo, debes ir incrementando esa posición: puntero+1, puntero+2, puntero+n. Luego se inventaron el acceso tipo puntero[n], pero para que conservar la compatibilidad con la notación de suma de punteros, tenía que comenzar por 0. Así, puntero[0] es lo mismo que decir arreglo+0. Si los arreglos comenzaran en 1, tendrías que saber cuándo usar 1 y cuándo 0: puntero[1] == puntero+0.
Luego vinieron los descendientes de C que, aún sin necesitarlo (porque ya no almacenan los arreglos de esta forma y no se puede acceder multiplicando el puntero por el índice), conservaron la notación por compatibilidad. Excepciones: lenguajes que nada tienen que ver con C como Pascal, en el que el estándar es acceder con [indice]. Por esto el índice puede comenzar en 1 o cualquier otro número, ya que el lenguaje se encarga del resto internamente.
#37:
#28 VB no es que empiece en el 1, es peor aún.
Tu declaras un array tal que así: Dim foo(5) As Integer
Y resulta que el array tiene 6 posiciones, que son: foo(0), foo(1), foo(2), foo(3), foo(4), foo(5)
Es lo tercero más estupido que he visto en mi vida. Lo segundo es la paja mental de Null vs Nothing, y lo primero es Javascript en general.
Una lanza en favor de todos los programadores que tenemos amigos que nos llaman "informáticos". HASTA LA P... de que me pidan arreglar ordenadores
#11:
#10 Como exageración es graciosa pero le falta la otra mitad, también humorística.
Porque te darías cuenta de que esa percha a superado numerosos test que demuestran que cumple a la perfección su cometido, y que la rueda pegada con cinta americana aguantará perfectamente incluso ante casos extremos y coincidencias que se dan una vez en un millón como que el avión aterrice sobre un centavo en vertical.
#24:
#22Poco ha programado éste para decir semejante estupidez.
.
#6:
#5#3 ¿No podríais pasaros por casa un rato a sintonizarme la TDT?
#20:
#14 En realidad, esa mirada que comentas va acompañada de un "¿Entonces qué clase de informático eres? ¿Esque no os enseñan nada en la universidad?"
#84:
#70 Si, es la que usaba Nokia y otros tantos, si quieres ser totalmente fulminado por la competencia en un par de años es la mejor tactica.
#23:
El punto 3 lo he tenido que argumentar muy a menudo. Un programador no tiene porque saber arreglarte el ordenador.
A menudo uso el símil entre un conductor y un mecánico.
El programador sería como el conductor que sabe como sacar el máximo provecho del coche. Exprimir sus capacidades para lograr llegar al objetivo. Incluso tiene nociones de como funciona internamente el motor. Pero nada mas.
El "técnico en hardware" es el verdadero mecánico. A lo mejor el no sabe sumar dos mas dos, ni como ordenar una array(ni siquiera sabe que es una array), pero sabe como funciona el ordenador físicamente. Que es cada pieza y como arreglarla.
#2 Puede ser cierto para el legacy code, pero un software moderno desarrollado con metodologías modernas es una pieza muy precisa y testeada.
La limpieza del código, su legibilidad, su mantenibilidad son de los factores más importantes en todo proyecto de software.
Excepto en los sprints y o en el prototipado rápido de un producto mínimo viable, el tiempo invertido en tests y refactorizaciones es tanto como el invertido en añadir nuevas funcionalidades.
#3 Es tan sencillo como decir "no tengo ni idea, cuando en la empresa tengo un problema, llamo a sistemas". Con esa respuesta, llevo más de 10 años sin arreglar un ordenador que no sea mio.
#c-4" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2372568/order/4">#4 Poco has programado tú. Normalmente un programa con metodologías modernas y tecnologías actuales tiene que coexistir con programas anteriores de la misma empresa o del antiguo proveedor de servicios del cliente. Esto provoca que haya que hacer mil pirulas para comunicar unas aplicaciones/funcionalidades con otras.
Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón, pero la realidad es que las empresas no tienen tantos recursos como para dedicar media plantilla a seguir dando soporte a la aplicación vieja mientras otra media plantilla desarrolla la nueva. Las cosas se van haciendo poco a poco, cuando el cliente aprieta, e integrando lo nuevo con lo que ya hay.
Te voy a poner un ejemplo de la multinacional en la que trabajo. Tenían una aplicación de escritorio, que migró a internet (html 2), que luego fue reconvertida a otra tecnología web que quedó obsoleta, y luego pasó a html5. Eso convive con otros servicios que automatizan tareas, fuera de la aplicación manejada por el cliente. En total, coexisten aplicaciones en javascript, html, asp, c#, c++, c++ builder, visual c, oracle, sqlite, office y alguna más que se me escapa. Todo en un delicado equilibrio.
#8 Yo no he dicho que sea un caos. Lo que digo es que la aserción 1 tiene razón:
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Que hay un todo que funciona gracias a un montón de ñapas que conectan unas partes con otras. Que es como viajar en un 747 y darte cuenta de que el tubo de la gasolina está sujeto con una percha y que la rueda de aterrizaje está pegada con cinta americana.
#10 Como exageración es graciosa pero le falta la otra mitad, también humorística.
Porque te darías cuenta de que esa percha a superado numerosos test que demuestran que cumple a la perfección su cometido, y que la rueda pegada con cinta americana aguantará perfectamente incluso ante casos extremos y coincidencias que se dan una vez en un millón como que el avión aterrice sobre un centavo en vertical.
#11#10 ¡Pelea de gatas!. Cuando veo flames de estos siempre pienso que antes de discutir con alguien (en un campo en que ambos somos entendido en la materia) debemos conocer muy a fondo el bagaje del adversario, porque es muy importante no caer en la trampa de subestimar los conocimientos del oponente. Siempre digo que hay tres tipos de profesionales, los que saben, los que no, y los que "creen" que saben. Considerándome de los segundos, claro.
Dicho esto, soy de la opinión de que el punto 1 tiene más razón que un santo.
#5 Al principio cuesta un poco porque te miran con una mezcla de que les estés engañando y como pensando qué será lo que haces en el trabajo si no sabes hacer nada.
Estoy en otra startup donde estamos a la espera de que se firme un contrato con unos inversores (la firma es inminente desde febrero...)
En esa no sé que planes de contratación tienen.
#11 Eso mismo podría aplicar a cualquier otra ingeniería, lo que pasa es que el software en varios aspectos es mucho más flexible, tienes menos restricciones impuestas que sean totalmente inviolables, etc, y al final se hacen más ñapas.
Sin embargo, viendo algunos programas como el de megaestructuras, en la construcción del LHC se hicieron varias ñapas por cosas que no se habían tenido en cuenta. Y sí en un avión en vez de con un perchero utilizan la pieza D05-JSA pues yo no sé si es la más adecuada, pero es que igual quizás es una ñapa.
Quizás si yo supiera todo lo que se hace para construir un avión, ni volaría en uno...
El punto 3 lo he tenido que argumentar muy a menudo. Un programador no tiene porque saber arreglarte el ordenador.
A menudo uso el símil entre un conductor y un mecánico.
El programador sería como el conductor que sabe como sacar el máximo provecho del coche. Exprimir sus capacidades para lograr llegar al objetivo. Incluso tiene nociones de como funciona internamente el motor. Pero nada mas.
El "técnico en hardware" es el verdadero mecánico. A lo mejor el no sabe sumar dos mas dos, ni como ordenar una array(ni siquiera sabe que es una array), pero sabe como funciona el ordenador físicamente. Que es cada pieza y como arreglarla.
#24 En la inmensa mayoría de los casos en el cero. Creo que en alguna versión de Basic empezaban por 1 y quizá haya algún otro por ahí, pero desde luego la minoría. No sé yo quién será el que ha programado poco.
Como estudiante de programación, mi verdad en programación y la vida es esta: No lo puedes tener todo a la vez.
Un algoritmo puede ser bueno para una cosa, pero es malo para otra. Si es buenísimo para una cosa, probablemente es pésima para otras. Y si resulta ser bueno en todo lo que se le pide, entonces es extremadamente complejo, y por tanto, lleno de posibles errores.
El último es cierto y no solo en la informática, cuanta gente farda de no leer un libro, de pasar de la cultura, de vivir rodeado de tecnología y no entender ni papa... en fin... que lo diga mi padre, pues todavía, aunque para él es una mierda no saber de informática, pero que lo diga alguien de mi generación y con una sonrisa en la cara es para echarse a llorar.
Si mañana heredo una torre de pisos en la Castellana, si quiero saber cuántas plantas tiene, empezaré a recorrerlas desde la planta baja contando desde 1. Si quiero ponerles un letrero, empezaré a recorrerlas desde la planta baja numerando desde 0.
#5 Pero... ¿podrías pasarte por mi casa a echarle un vistazo al microondas, que lo del grill no va bien del todo? Total, si a ti no te va a costar nada...
Y si me lo arreglas te invito a una cerveza.
Bienvenidos al mundo real. Eso pasa en casi todos los campos. Por poner un ejemplo, cuando vas al super y compras una bolsa de patatas tú ves un producto acabado en el que todo está correcto, si viéseis la fábrica...
#3, 3 buenos trucos para evitar esas reparaciones:
1) Decir "Traemelo a casa y lo miro": El 90% de las personas no querrá hacerlo por pura vagancia. Si piden un favor y no son capaces de llevarte el bicho, no son merecedores de ninguna ayuda.
2) Decir que eres usuario de linux desde hay 10 años y que no conoces windows lo suficiente.
3) Hacerlo con la condición de que se vista de gallina y te haga una paella.
#3 extrapolable con muy pocos cambios a otras profesiones (por ejemplo, la medicina (exagerando ):
¿tú sabes porqué cuando levanto el brazo derecho y me toco la ceja izquierda me duele justo en la parte ésta que me estoy tocando? pero solo me pasa cuando hago ese movimiento los días pares y si, además, he comido judías... )
Alguien que me diga qué pinta el punto 8 en esa lista. Es como decir: Fact 10: When you boot your computer, the processor starts working
El punto 5, lo de que empieza a contar desde 0, pues bien, deformación profesional, pero en el mundo real ve al banco a retirar pasta y que el cajero te devuelva 10 billetes contando del 0 al 9 (por poner un ejemplo), a ver si tu cerebro es tan "cool" cuando se trata de pasta.
#38#37 A mi eso me demuestra que Javascript sigue siendo el lenguaje más incomprendido del mundo. Llevo un año con este lenguaje y cada vez me gusta más. Ya no echo de menos Java para nada.
#1 Creo que se refiere a que cuando conoces bien algo también llegas a conocer sus debilidades y puntos críticos. Eso ocure cuando sabes "mirar bajo el capó" y entender lo que hay debajo y lo que puede haber. Ejemplo: cuando te conectas a una wifi abierta y desconocida y navegas a través de sistemas de terceros que examinan y almacenan tus datos. O como cuando whatsapp no encriptaba los mensajes y los trasmitía por canal inseguro...
Sí, y también hay mucha gente que no sabe inglés, ni sabe usar el traductor y que??. Es curioso aquí en meneamé hablan mucho de programadores, que saben cosas que el resto no sabe, que están un escalón por encima y cosas de ese tipo. Algún tipo de complejo tienen que tener para darse tantos aires. https://sites.google.com/site/codigodedescuento/codigo-promocional-groupalia
Pues yo tengo en mi empresa un administrador de sistemas cojonudo que lo primero que hago es preguntarle -cómo buscar esto o aquello en google- (porque no siempre se donde o cómo) él me da una guía, lo miro por mi cuenta uno o dos días (o una semana) y si no lo consigo le pido ayuda y él siempre está encantado.
Después siempre le compro cerveza alemana en agradecimiento, me ayude o me diga cómo buscar en google.
Eso si, si después él me pide cualquier cosa, en 5 minutos le estoy ayudando también, como si me pide que le ayude a pintar su casa.
#11 lo unico que demuestran los tests es que el funcionamiento basico es correcto y que los bugs detectados no ocurrirán. No dicen nada de los bugs no detectados, y sobre todo, hablan de que la finalidad se cumple, no de cómo se cumple. Un software bien testeado es mucho mejor que uno sin testear, pero pueden tener la misma cantidad de chapuzas dentro.
Interesante ... y ¿los admins/aquitectos de sistemas que somos?
Por que yo me meto entre pecho y espalda cada script en bash, ksh, Perl, Python/Jython (Weblogic) y en ocasiones hasta Php y C que flipo, sin contar con SQL (incluyendo PL).
Para buscar cagadas de los programadores (nadie es perfecto) y revisión del diseño de las BBDD para cortar deditos.
Y soy un admin. No, no soy un hombre orquesta ni trabajo en una Pyme.
#61 Yo doy gracias por el advenimiento de jquery. Hasta entonces, las batallas de las distintas librerías de Js para hacer cualquier cosa eran épicas (y aleatorias).
A ver ... que no lo digo para ofender a nadie, pero que se perfectamente que es un algortimo y cantarle las 40 a quien programa con el culo y me deja la máquina frita
#7Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón,
En mi experiencia los que dicen eso son nuevos programadores con muy poca experiencia.
Dile tú a un banco que estaría bien quitar código COBOL que lleva funcionando 40 años, que será muy feo y lo que quieras pero que funciona como un reloj y que lo vas a cambiar por otra cosa que te vas a picar de cero usando la novedad de la semana.
Por cierto, otra verdad que los programadores con experiencia saben: Nuestro propio código revisado 10 años después nos suele parecer una puta mierda.
A muchos nos da pereza leer en inglés o simplemente no lo dominamos. Pero que no se entere el resto, que somos gente de tecnología y nuestro dominio del inglés es incuestionable.
#60 Yo quiero un sub donde los admin de sistemas podamos llorar agusto.
1) En desarrollo funciona perfecto.
2) La aplicacion va fluida, el servidor necesita mad RAM
3) No sabemos nada de ese bloq en la BBDD las consultas tienen un timeout adecuado.
4) El servidor quadcore, es un poco escaso, el fabricante recimienda un opteron
Etc... mandarme la buambulancia me la he ganado.
#7 Sí, esa es la dura realidad, pero no significa que deba ser así. Ahí hay algo de cabezonería y tacañería de las grandes empresas. Todo programa es susceptible de ser reescrito de una mejor forma, mejor documentado, optimizado, más preparado para manejar errores ya conocidos durante su uso en producción. Sólo que actualizarlos cuesta dinero y las empresas siguen eso de "si funciona no lo toques y menos si nos cuesta dinero". Si sólo se dieran cuenta de los problemas (y dinero) que se ahorrarían actualizando el código obsoleto, se convertiría en una prioridad hacerlo.
#78 Cierto. Cuando empecé a programar (Pascal), para mí era natural empezar siempre en uno. Cuando pasé a otros lenguajes no entendía qué pasaba por la mente de quienes los hicieron. ¿Qué clase de mente retorcida comienza un arreglo en cero?
#46 Puede que tengas razón, pero yo en algunos proyectos, de tanto callback he acabado con un código espagueti inmanejable. Admito que puede ser culpa mía, por falta de metodología adecuada o lo que sea. Pero ese mismo código en java, por decir uno, no me ocurre.
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Todas estas ñapas funcionan hasta que dejan de funcionar, o hasta que las tienen que mantener o reparar otras personas.
Por eso a los que piensan, diseñan y programan así, nunca hay que dejarles que programen sistemas para centrales nucleares, software para dispositivos medicos, software para dispositivos que vayan a ser instalados en aviones u otros sistemas criticos, como por ejemplo sistemas que controlan los sistemas electricos de ciudades, o sistemas críticos para la seguridad nacional (como por ejemplo si la privacidad de determinados datos son criticos para la seguridad).
De hecho si os leeis los acuerdos de licencia de windows, mac os x, ... habrá una parte en que dice que ese software vale para sistemas de usuarios, pero no para centrales nucleares, aparatos medicos u otros sistémas críticos.
#22#24#28#32#42#45 Supongo que ya lo sabéis, pero el que los arreglos comiencen por 0 no es ningún capricho de algún programador que lo decidió así porque le salió de los cojones. Viene de los lenguajes que tratan al arreglo como posiciones contiguas en memoria. El caso más común es el de C: cuando creas un arreglo en C, lo que obtienes es la posición en memoria del primer elemento, es decir, puntero+0 (puntero es la posición del arreglo en memoria). Para recorrer el resto del arreglo, debes ir incrementando esa posición: puntero+1, puntero+2, puntero+n. Luego se inventaron el acceso tipo puntero[n], pero para que conservar la compatibilidad con la notación de suma de punteros, tenía que comenzar por 0. Así, puntero[0] es lo mismo que decir arreglo+0. Si los arreglos comenzaran en 1, tendrías que saber cuándo usar 1 y cuándo 0: puntero[1] == puntero+0.
Luego vinieron los descendientes de C que, aún sin necesitarlo (porque ya no almacenan los arreglos de esta forma y no se puede acceder multiplicando el puntero por el índice), conservaron la notación por compatibilidad. Excepciones: lenguajes que nada tienen que ver con C como Pascal, en el que el estándar es acceder con [indice]. Por esto el índice puede comenzar en 1 o cualquier otro número, ya que el lenguaje se encarga del resto internamente.
Comentarios
No estoy de acuerdo con el punto 1.
#1 Explanation needed.
La 3 debería ser enseñada en los colegios.
Una lanza en favor de todos los programadores que tenemos amigos que nos llaman "informáticos". HASTA LA P... de que me pidan arreglar ordenadores
#2 Puede ser cierto para el legacy code, pero un software moderno desarrollado con metodologías modernas es una pieza muy precisa y testeada.
La limpieza del código, su legibilidad, su mantenibilidad son de los factores más importantes en todo proyecto de software.
Excepto en los sprints y o en el prototipado rápido de un producto mínimo viable, el tiempo invertido en tests y refactorizaciones es tanto como el invertido en añadir nuevas funcionalidades.
#3 Es tan sencillo como decir "no tengo ni idea, cuando en la empresa tengo un problema, llamo a sistemas". Con esa respuesta, llevo más de 10 años sin arreglar un ordenador que no sea mio.
#5 #3 ¿No podríais pasaros por casa un rato a sintonizarme la TDT?
#c-4" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/2372568/order/4">#4 Poco has programado tú. Normalmente un programa con metodologías modernas y tecnologías actuales tiene que coexistir con programas anteriores de la misma empresa o del antiguo proveedor de servicios del cliente. Esto provoca que haya que hacer mil pirulas para comunicar unas aplicaciones/funcionalidades con otras.
Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón, pero la realidad es que las empresas no tienen tantos recursos como para dedicar media plantilla a seguir dando soporte a la aplicación vieja mientras otra media plantilla desarrolla la nueva. Las cosas se van haciendo poco a poco, cuando el cliente aprieta, e integrando lo nuevo con lo que ya hay.
Te voy a poner un ejemplo de la multinacional en la que trabajo. Tenían una aplicación de escritorio, que migró a internet (html 2), que luego fue reconvertida a otra tecnología web que quedó obsoleta, y luego pasó a html5. Eso convive con otros servicios que automatizan tareas, fuera de la aplicación manejada por el cliente. En total, coexisten aplicaciones en javascript, html, asp, c#, c++, c++ builder, visual c, oracle, sqlite, office y alguna más que se me escapa. Todo en un delicado equilibrio.
#7 Si sigues la máxima de dejar el código mejor de como lo encontraste no termina todo siendo un caos.
#3 Te inventas una avería física. Le dices que hay que cambiarle la junta de la trócola y que cuesta X. Así tiene dos opciones, pagarte, o llevárselo.
#8 Yo no he dicho que sea un caos. Lo que digo es que la aserción 1 tiene razón:
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Que hay un todo que funciona gracias a un montón de ñapas que conectan unas partes con otras. Que es como viajar en un 747 y darte cuenta de que el tubo de la gasolina está sujeto con una percha y que la rueda de aterrizaje está pegada con cinta americana.
#10 Como exageración es graciosa pero le falta la otra mitad, también humorística.
Porque te darías cuenta de que esa percha a superado numerosos test que demuestran que cumple a la perfección su cometido, y que la rueda pegada con cinta americana aguantará perfectamente incluso ante casos extremos y coincidencias que se dan una vez en un millón como que el avión aterrice sobre un centavo en vertical.
#11 Me gustaría trabajar en tu empresa, porque en la mía cuando la percha comienza a fallar la pegan con un chicle ¿Estáis buscando A/P?
#11 #10 ¡Pelea de gatas!. Cuando veo flames de estos siempre pienso que antes de discutir con alguien (en un campo en que ambos somos entendido en la materia) debemos conocer muy a fondo el bagaje del adversario, porque es muy importante no caer en la trampa de subestimar los conocimientos del oponente. Siempre digo que hay tres tipos de profesionales, los que saben, los que no, y los que "creen" que saben. Considerándome de los segundos, claro.
Dicho esto, soy de la opinión de que el punto 1 tiene más razón que un santo.
#5 Al principio cuesta un poco porque te miran con una mezcla de que les estés engañando y como pensando qué será lo que haces en el trabajo si no sabes hacer nada.
#12 Startup sin financiación.
Está previsto empezar a facturar en abril.
Lo que buscamos son administradores de sistemas, pero podemos valorar desarrolladores con experiencia en las tecnologías que usamos.
Docker, elasticsearch, mongo, node, express, handlebars, angular, bootstrap
Estoy en otra startup donde estamos a la espera de que se firme un contrato con unos inversores (la firma es inminente desde febrero...)
En esa no sé que planes de contratación tienen.
En el punto 2 creo que se han quedado corto.
#15 Uff, de todas esas la única que se me da bien es hacer el mongo.
Programador = /= Técnico
Igual que conductor de automóvil =/= Mecanico
Super fan del 4 y el 7
#14 En realidad, esa mirada que comentas va acompañada de un "¿Entonces qué clase de informático eres? ¿Esque no os enseñan nada en la universidad?"
#11 Eso mismo podría aplicar a cualquier otra ingeniería, lo que pasa es que el software en varios aspectos es mucho más flexible, tienes menos restricciones impuestas que sean totalmente inviolables, etc, y al final se hacen más ñapas.
Sin embargo, viendo algunos programas como el de megaestructuras, en la construcción del LHC se hicieron varias ñapas por cosas que no se habían tenido en cuenta. Y sí en un avión en vez de con un perchero utilizan la pieza D05-JSA pues yo no sé si es la más adecuada, pero es que igual quizás es una ñapa.
Quizás si yo supiera todo lo que se hace para construir un avión, ni volaría en uno...
Fact 5
Counting starts from zero, not one.
Poco ha programado éste para decir semejante estupidez.
No sé por qué mnm ha colocado mi comentario aquí
El punto 3 lo he tenido que argumentar muy a menudo. Un programador no tiene porque saber arreglarte el ordenador.
A menudo uso el símil entre un conductor y un mecánico.
El programador sería como el conductor que sabe como sacar el máximo provecho del coche. Exprimir sus capacidades para lograr llegar al objetivo. Incluso tiene nociones de como funciona internamente el motor. Pero nada mas.
El "técnico en hardware" es el verdadero mecánico. A lo mejor el no sabe sumar dos mas dos, ni como ordenar una array(ni siquiera sabe que es una array), pero sabe como funciona el ordenador físicamente. Que es cada pieza y como arreglarla.
#22 Poco ha programado éste para decir semejante estupidez.
.
#4 PHP.
Déjate un punto y coma en el sitio equivocado y puedes descojonar una web entera.
#25 Hombre, poder puedes. No sólo con PHP, sino con cualquier lenguaje (que yo sepa todos tienen sintaxis por definición).
Ahora bien, para eso tienes un servidor de desarrollo y otro de producción (y dependiendo de lo grande que sea la empresa, de pruebas, etc.).
Subir código a producción sin probarlo antes (aunque sea a pinrel) es una temeridad. Si no lo aprendes por las buenas, lo aprendes por las malas.
#1 ni yo en el 0
#24 En la inmensa mayoría de los casos en el cero. Creo que en alguna versión de Basic empezaban por 1 y quizá haya algún otro por ahí, pero desde luego la minoría. No sé yo quién será el que ha programado poco.
Como estudiante de programación, mi verdad en programación y la vida es esta: No lo puedes tener todo a la vez.
Un algoritmo puede ser bueno para una cosa, pero es malo para otra. Si es buenísimo para una cosa, probablemente es pésima para otras. Y si resulta ser bueno en todo lo que se le pide, entonces es extremadamente complejo, y por tanto, lleno de posibles errores.
Rapidez, memoria y complejidad. Escoge dos.
La profesión del programador es como la del camarero. Solo el camarero sabe lo que hay al otro lado de la barra. Y es inquietante.
El último es cierto y no solo en la informática, cuanta gente farda de no leer un libro, de pasar de la cultura, de vivir rodeado de tecnología y no entender ni papa... en fin... que lo diga mi padre, pues todavía, aunque para él es una mierda no saber de informática, pero que lo diga alguien de mi generación y con una sonrisa en la cara es para echarse a llorar.
#22 Contar empieza por 1.
Numerar empieza por 0.
No es lo mismo.
Si mañana heredo una torre de pisos en la Castellana, si quiero saber cuántas plantas tiene, empezaré a recorrerlas desde la planta baja contando desde 1. Si quiero ponerles un letrero, empezaré a recorrerlas desde la planta baja numerando desde 0.
#9 Relacionada con tu comentario: Alternativas a la junta de la trócola: 7 piezas de tu coche de las que jamás habías oído hablar
Alternativas a la junta de la trócola: 7 piezas de...
motorpasion.comEl punto nueve me recuerda la frase: Es que yo soy de letras
#5 Pero... ¿podrías pasarte por mi casa a echarle un vistazo al microondas, que lo del grill no va bien del todo? Total, si a ti no te va a costar nada...
Y si me lo arreglas te invito a una cerveza.
Bienvenidos al mundo real. Eso pasa en casi todos los campos. Por poner un ejemplo, cuando vas al super y compras una bolsa de patatas tú ves un producto acabado en el que todo está correcto, si viéseis la fábrica...
#28 VB no es que empiece en el 1, es peor aún.
Tu declaras un array tal que así:
Dim foo(5) As Integer
Y resulta que el array tiene 6 posiciones, que son: foo(0), foo(1), foo(2), foo(3), foo(4), foo(5)
Es lo tercero más estupido que he visto en mi vida. Lo segundo es la paja mental de Null vs Nothing, y lo primero es Javascript en general.
#37 positivo solo por las últimas cinco palabras.
#3, 3 buenos trucos para evitar esas reparaciones:
1) Decir "Traemelo a casa y lo miro": El 90% de las personas no querrá hacerlo por pura vagancia. Si piden un favor y no son capaces de llevarte el bicho, no son merecedores de ninguna ayuda.
2) Decir que eres usuario de linux desde hay 10 años y que no conoces windows lo suficiente.
3) Hacerlo con la condición de que se vista de gallina y te haga una paella.
#3 extrapolable con muy pocos cambios a otras profesiones (por ejemplo, la medicina (exagerando ):
¿tú sabes porqué cuando levanto el brazo derecho y me toco la ceja izquierda me duele justo en la parte ésta que me estoy tocando? pero solo me pasa cuando hago ese movimiento los días pares y si, además, he comido judías... )
#30 Y el mecanico, albañil, cirujano...la entradilla es un poco chorra.
#24 en pascal se empieza a contar en 1.
Para mi programar es crear, por eso me encanta.
#18 no.
Programador != técnico
Igual que diseñador de automoviles != mecanico
Igual que dios != medico
O algo así
Alguien que me diga qué pinta el punto 8 en esa lista. Es como decir:
Fact 10: When you boot your computer, the processor starts working
El punto 5, lo de que empieza a contar desde 0, pues bien, deformación profesional, pero en el mundo real ve al banco a retirar pasta y que el cajero te devuelva 10 billetes contando del 0 al 9 (por poner un ejemplo), a ver si tu cerebro es tan "cool" cuando se trata de pasta.
El resto de puntos ok.
#38 #37 A mi eso me demuestra que Javascript sigue siendo el lenguaje más incomprendido del mundo. Llevo un año con este lenguaje y cada vez me gusta más. Ya no echo de menos Java para nada.
#1 Creo que se refiere a que cuando conoces bien algo también llegas a conocer sus debilidades y puntos críticos. Eso ocure cuando sabes "mirar bajo el capó" y entender lo que hay debajo y lo que puede haber. Ejemplo: cuando te conectas a una wifi abierta y desconocida y navegas a través de sistemas de terceros que examinan y almacenan tus datos. O como cuando whatsapp no encriptaba los mensajes y los trasmitía por canal inseguro...
#42 pues si:
http://rosettacode.org/wiki/Retrieving_an_Element_of_an_Array#Delphi.2FObject_Pascal.2FStandard_Pascal
foo : array[1..10] of integer;
Sí, y también hay mucha gente que no sabe inglés, ni sabe usar el traductor y que??. Es curioso aquí en meneamé hablan mucho de programadores, que saben cosas que el resto no sabe, que están un escalón por encima y cosas de ese tipo. Algún tipo de complejo tienen que tener para darse tantos aires.
https://sites.google.com/site/codigodedescuento/codigo-promocional-groupalia
#44 Depende del lenguaje unos se pone != otros !== o otros directamente ni los nombro.
#24 Otro que empieza desde 1
#3 "pringaohowto.txt" te solucionará la vida... (googlealo)
Erronea. Acorde al punto 5, debieran ser 8 verdades y empezar en Fact #0
"That about 25% of the hours spent writing an application are spent figuring out ways the end user will do something wrong."
Esto es algo común en el campo de la ingenierá en general.
#7 yo creo que #4 está empezando en el mundo laboral y desarrolla páginas webs o temas Android o cosas así, porque si no no me explico su comentario.
Pues yo tengo en mi empresa un administrador de sistemas cojonudo que lo primero que hago es preguntarle -cómo buscar esto o aquello en google- (porque no siempre se donde o cómo) él me da una guía, lo miro por mi cuenta uno o dos días (o una semana) y si no lo consigo le pido ayuda y él siempre está encantado.
Después siempre le compro cerveza alemana en agradecimiento, me ayude o me diga cómo buscar en google.
Eso si, si después él me pide cualquier cosa, en 5 minutos le estoy ayudando también, como si me pide que le ayude a pintar su casa.
#11 lo unico que demuestran los tests es que el funcionamiento basico es correcto y que los bugs detectados no ocurrirán. No dicen nada de los bugs no detectados, y sobre todo, hablan de que la finalidad se cumple, no de cómo se cumple. Un software bien testeado es mucho mejor que uno sin testear, pero pueden tener la misma cantidad de chapuzas dentro.
Interesante ... y ¿los admins/aquitectos de sistemas que somos?
Por que yo me meto entre pecho y espalda cada script en bash, ksh, Perl, Python/Jython (Weblogic) y en ocasiones hasta Php y C que flipo, sin contar con SQL (incluyendo PL).
Para buscar cagadas de los programadores (nadie es perfecto) y revisión del diseño de las BBDD para cortar deditos.
Y soy un admin. No, no soy un hombre orquesta ni trabajo en una Pyme.
Saluditos vecinitos
#46 Al menos admitirás que Javascript se parece a Java lo que una pepsi a una lavadora.
Es aquí donde los programadores os chupais las pollas unos a otros?
#59 Javascript is to Java as hamburguer is to ham
Para mí lo peor de Js es el nombre, que crea falsas expectativas.
#25 C. Cómete un asterisco de dos y observa como ese puntero va a tomar por culo cuando menos te lo esperas.
#61 Yo doy gracias por el advenimiento de jquery. Hasta entonces, las batallas de las distintas librerías de Js para hacer cualquier cosa eran épicas (y aleatorias).
#60 no seas así hombre .
A ver ... que no lo digo para ofender a nadie, pero que se perfectamente que es un algortimo y cantarle las 40 a quien programa con el culo y me deja la máquina frita
#4 que tierno....
Dile al cliente q vas a hacerlo todo súper bien y q solo le ca a salir el doble de caro y le va a costar el doble de tiempo, veras q bien....
#50 ¿En qué lenguajes se pone !==?
#66 Supongo que ha confundido el comparador de tipo !== (de varios lenguajes) con el comparador de diferencia !=.
Ha querido ir de listo, de todos modos no sé si no ha entendido mi comentario o ha desviado el tema sin más.
Podría haber dicho que en otros lenguajes se utiliza (si, si, incluso para strings), que desafortunado la verdad.
cc/ #50
#7 Lo ideal sería abandonar el programa "viejo" y usar el "nuevo" del tirón,
En mi experiencia los que dicen eso son nuevos programadores con muy poca experiencia.
Dile tú a un banco que estaría bien quitar código COBOL que lleva funcionando 40 años, que será muy feo y lo que quieras pero que funciona como un reloj y que lo vas a cambiar por otra cosa que te vas a picar de cero usando la novedad de la semana.
Por cierto, otra verdad que los programadores con experiencia saben: Nuestro propio código revisado 10 años después nos suele parecer una puta mierda.
Ñapas...
#8 la máxima es «si funciona, no lo toques!»
La #3 la voy a grabar en una placa de mármol.
#35 A mi me lo han pedido, literalmente, true story.
#29 fácil elección... Si algo esta bien hecho y funciona rápido usando poca memoria no tengo pq saber como funciona caja negra powa
#32 Pues hay un montón de programadores de ascensores que te vuelven loco para saber cual es el botón de la planta baja.
Verdad # 10
A muchos nos da pereza leer en inglés o simplemente no lo dominamos. Pero que no se entere el resto, que somos gente de tecnología y nuestro dominio del inglés es incuestionable.
#60 Yo quiero un sub donde los admin de sistemas podamos llorar agusto.
1) En desarrollo funciona perfecto.
2) La aplicacion va fluida, el servidor necesita mad RAM
3) No sabemos nada de ese bloq en la BBDD las consultas tienen un timeout adecuado.
4) El servidor quadcore, es un poco escaso, el fabricante recimienda un opteron
Etc... mandarme la buambulancia me la he ganado.
#75 bastante penosa esa verdad
Yo si puedo elegir entre leer en castellano e inglés, siempre inglés. Es la forma de que al final te cueste prácticamente lo mismo.
"Counting starts from zero, not one" Puto delphi: algunos índices empiezan en cero y otros en uno.
#7 Sí, esa es la dura realidad, pero no significa que deba ser así. Ahí hay algo de cabezonería y tacañería de las grandes empresas. Todo programa es susceptible de ser reescrito de una mejor forma, mejor documentado, optimizado, más preparado para manejar errores ya conocidos durante su uso en producción. Sólo que actualizarlos cuesta dinero y las empresas siguen eso de "si funciona no lo toques y menos si nos cuesta dinero". Si sólo se dieran cuenta de los problemas (y dinero) que se ahorrarían actualizando el código obsoleto, se convertiría en una prioridad hacerlo.
#78 Cierto. Cuando empecé a programar (Pascal), para mí era natural empezar siempre en uno. Cuando pasé a otros lenguajes no entendía qué pasaba por la mente de quienes los hicieron. ¿Qué clase de mente retorcida comienza un arreglo en cero?
#46 Puede que tengas razón, pero yo en algunos proyectos, de tanto callback he acabado con un código espagueti inmanejable. Admito que puede ser culpa mía, por falta de metodología adecuada o lo que sea. Pero ese mismo código en java, por decir uno, no me ocurre.
#63 http://youmightnotneedjquery.com/
La cosa ha cambiado en los últimos años, por suerte
#24 también en Matlab el primer índice es el 1.
#70 Si, es la que usaba Nokia y otros tantos, si quieres ser totalmente fulminado por la competencia en un par de años es la mejor tactica.
#81 A veces es complicado evitar eso, pero hay maneras de mitigarlo: http://callbackhell.com/
#15 Veo todas esas tecnologías y subo otras cinco más.
¿Alguien quiere trabajar en mi startup?
#55 ¿Qué desarrollas tú y cuál es tu experiencia en ello? Por curiosidad, más que nada.
#42 En Modula-2 se empieza como quieras:
TYPE ArrayDef = ARRAY[12..25] OF INTEGER;
#86 qué 5?
Yo no ofrezco trabajo.
He dicho claramente que ni tengo financiación ni estoy facturando.
Cuando contratemos será a sysadmins.
#62 Es lo que tienen los malvados compiladores, suelen tomarse en serio el análisis sintáctico.
#90 O cuando no el preprocesador se ríe en tu jeta.
#65 efectivamente.
Supón que el dinero no es un problema:
¿Que prefieres un mercedes o un Tata?
#90 Si PHP al colegayonseca le parece chungo, mejor que no vea esto:
http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest
#46 Te compadezco por haber tenido que ganarte el pan en los dos lenguajes más mierders conocidos por la humanidad.
"Under the hood, most critical software you use every day (like Mac OS X, or Facebook) contains a terrifying number of hacks and shortcuts that happen to barely fit together into a working whole. It would be like taking apart a brand-new 747 and discovering that the fuel line is held in place by a coat-hanger and the landing gear is attached with duct tape."
Todas estas ñapas funcionan hasta que dejan de funcionar, o hasta que las tienen que mantener o reparar otras personas.
Por eso a los que piensan, diseñan y programan así, nunca hay que dejarles que programen sistemas para centrales nucleares, software para dispositivos medicos, software para dispositivos que vayan a ser instalados en aviones u otros sistemas criticos, como por ejemplo sistemas que controlan los sistemas electricos de ciudades, o sistemas críticos para la seguridad nacional (como por ejemplo si la privacidad de determinados datos son criticos para la seguridad).
De hecho si os leeis los acuerdos de licencia de windows, mac os x, ... habrá una parte en que dice que ese software vale para sistemas de usuarios, pero no para centrales nucleares, aparatos medicos u otros sistémas críticos.
Relacionado
Una línea de código fue capaz de congelar el tráfico aéreo de UK durante una hora
Una línea de código fue capaz de congelar el tráfico aéreo de UK durante una hora
Una línea de código fue capaz de congelar el tráfi...
xataka.comLa última actualización de Panda Antivirus deja el ordenador inútil
La última actualización de Panda Antivirus deja el ordenador inútil
La última actualización de Panda Antivirus deja el...
elgrupoinformatico.comGoogle filtra por error los datos privados de 280000 dominios (en)
Google filtra por error los datos privados de 280000 dominios (en)
Google filtra por error los datos privados de 2800...
arstechnica.comFacebook soluciona grave vulnerabilidad que permitia a un atacante borrar cualquier fotografía de un album
Facebook soluciona grave vulnerabilidad que permitia a un atacante borrar cualquier fotografía de un album
Facebook soluciona grave vulnerabilidad que permit...
blog.elhacker.net«Hackers» de todo el mundo compensan al pirata informático al que Facebook no quiso pagar
«Hackers» de todo el mundo compensan al pirata informático al que Facebook no quiso pagar
«Hackers» de todo el mundo compensan al pirata inf...
lavozdegalicia.esUna actualización de Windows 7 provoca reinicios
Una actualización de Windows 7 provoca reinicios
Una actualización de Windows 7 provoca reinicios
elgrupoinformatico.comUn ingeniero de Google denuncia una cantidad "vergonzosamente grave" de errores en Flash Player
Un ingeniero de Google denuncia una cantidad "vergonzosamente grave" de errores en Flash Player
Un ingeniero de Google denuncia una cantidad "...
genbeta.comPor ejemplo
http://es.slideshare.net/jorarome/anlisis-de-modelos-de-evaluacin-de-calidad-de-software-libre
https://www.google.es/search?q=estandares+de+calidad+de+software
#22 #24 #28 #32 #42 #45 Supongo que ya lo sabéis, pero el que los arreglos comiencen por 0 no es ningún capricho de algún programador que lo decidió así porque le salió de los cojones. Viene de los lenguajes que tratan al arreglo como posiciones contiguas en memoria. El caso más común es el de C: cuando creas un arreglo en C, lo que obtienes es la posición en memoria del primer elemento, es decir, puntero+0 (puntero es la posición del arreglo en memoria). Para recorrer el resto del arreglo, debes ir incrementando esa posición: puntero+1, puntero+2, puntero+n. Luego se inventaron el acceso tipo puntero[n], pero para que conservar la compatibilidad con la notación de suma de punteros, tenía que comenzar por 0. Así, puntero[0] es lo mismo que decir arreglo+0. Si los arreglos comenzaran en 1, tendrías que saber cuándo usar 1 y cuándo 0: puntero[1] == puntero+0.
Luego vinieron los descendientes de C que, aún sin necesitarlo (porque ya no almacenan los arreglos de esta forma y no se puede acceder multiplicando el puntero por el índice), conservaron la notación por compatibilidad. Excepciones: lenguajes que nada tienen que ver con C como Pascal, en el que el estándar es acceder con [indice]. Por esto el índice puede comenzar en 1 o cualquier otro número, ya que el lenguaje se encarga del resto internamente.
Se empieza en el cero porque ese número historicamente define el offset del elemento, hijnorantes.
#3 Se me ha roto la tostadora. Si eso ya te invito a 1 caña.
#96 Donde dije "no se puede acceder multiplicando el puntero por el índice" quise decir "no se puede acceder sumando el puntero con el índice".
#67 No he querido de ir listo, aqui el se ha resbalado ahora eres tú
En Java también se pone !==, además de php creo que también sirve.
http://docs.oracle.com/javase/tutorial/java/nutsandbolts/op2.html