#10 Tazado no es eso, quiere decir ropa rozada por los pliegues. Lo ha escrito mal, quiere decir "tasada", es una falta corriente en sudamerica confundir S y Z.
#36 Si, estas equivocado.
CentOS es un "fork" de RHES, Fedora es el "laboratorio" para RHES igual que OpenJDK es el "laboratorio" para el JDK de Sun.
Fíjate en el software de CentOS, es en general más antiguo que el de la última versión de RHES, mientras que el software de Fedora es más moderno.
Eso sí CentOS es realmente como un RHES sin soporte de Red Hat.
#91 No es agradable, y el perpetrador es con toda probabilidad un desarrollador junior o alguien con muy poco respeto por sus compañeros... pero es también parte de nuestro trabajo aprender a lidiar con estos monstruos.
Y con eso no me refiero a aprender a resignarse, sino a aprender algunas técnicas y heurísticas que ayudan a entender mejor el código, debugarlo, refactorizarlo... algunas son más o menos universales, algunas dependen del lenguaje de programación que se esté usando... y algunas del proyecto en sí.
Lo que sí puedo decir es que tiro mucho de herramientas de análisis estático de código e IDEs potentes, rollo IntelliJ, que aligeran un poco la carga de trabajo, aunque te ponen la CPU a punto de freír huevos.
En cuanto a qué hacer a la hora de tratar con lenguajes "dinámicos" (no voy a entrar aquí en definiciones precisas, sé que hay mil sutilezas aquí), trato de anotar tipos siempre que sea posible (por ejemplo en Python y PHP se puede), aunque el código parezca más "denso", ayuda muchísimo.
Otro "truco" es tener los cojones de decirle a tu jefe que tardarás más de lo que él quiere y que da igual lo que insista, que es lo que hay. Y dedicar ese tiempo, con calma, a entender y mejorar el código. Y si te echan por eso, felicidades, ahora tienes tiempo para ir a un sitio mejor.
#91#71 creo que el primer programa que me tocó mantener en mi vida laboral fue un programa en C++, con punteros por todos lados (vamos, C con objetos...) y en el que me encontré una clase de 21k líneas que tenía una función de 6k líneas y hasta 16 niveles de condiciones.
No había ningún test y se sabía que esa función fallaba a veces, pero nadie se atrevía a tocarla.
Cabe decir que todos o casi todos los que desarrollaron esa monstruosidad eran tan Juniors que muchos no habían acabado la carrera.
#6 Por experiencia, la compilación cruzada no siempre es trivial. Me explico: hace unos años trabajé en un proyecto en el que desarrollábamos software para un cacharro con un micro raro, y necesitábamos tener webkit en él. La cuestión es que el fabricante sólo nos daba una versión concreta que no nos servía, por lo que teníamos que usar compilación cruzada. Usábamos una gentoo y sus herramientas, pero el problema era que la versión de webkit que necesitábamos no estaba disponible en gentoo, y cada vez que intentábamos nosotros hacer una compilación cruzada con las autotools, siempre fallaba en algún punto.
Al final desistimos, montamos el compilador en la propia placa y compilábamos sobre ella. Un día y pico necesitábamos para compilar una versión, pero al menos funcionaba.
Por eso no diría que la compilación cruzada no tiene ningún misterio: coger el gcc y decirle que te compile un fichero en C para otra arquitectura puede ser trivial, pero cuando tienes que compilar código que usa autotools o cmake puede ser una pesadilla. Por experiencia.
En mis 10 años de experiencia he de decir que jamás he visto a nadie, salvo en este año, que haya seguido esa reglas tan fundamentales.
No será que como ahora tienes 10 años de experiencia y has leído todo tipo de libros, ya no estás en empresas y equipos donde la gente sea tan junior? Te lo digo por que hace mucho mas de 10 años que existe el eXtreme programming, los patrones de diseño o libros como object oriented design heuristics.
#89 pero todo eso que comentas son cosas basicas y fundamentales de ingenieria, que se aprenden en toda la literatura de ingeniería de ciencias de la computación, que aprendiste exactamente de ese libro?
Lo pregunto en serio. Es un tema que me interesa entender.
#69 en el comentario #89 ya he comentado razones por que escribir código límpio y para mi la pena es que en 2019 la gente no sea un autentico talibán del código límpio. No sólo son líneas de código y parámetros de entrada, es también no indentar 3 if y dos fors, poner nombres de variables y nombres de funciones claros...
#14 de forma resumida, me podrías explicar que encontraste tan revelador en ese libro? veo que es una obra de referencia para muchos profesionales, y veo que tu caso es uno de esos, y me gustaría entenderlo mejor.
#64 poco codigo has visto, por mi lado he llegado a ver funciones de 2000 y pico lineas en ficheros de mas de 15000 lineas... todavia me entra el tembleque cuando lo recuerdo.
#64 La pena es que en 2019 la gente describa las propiedades del software en base a líneas de código o "cantidad" de parámetros de entrada de clases, que además describe con términos tan específicos como "monstruosas". En estos términos, es normal que ese libro sea tan popular.
Hay muchos otros libros, como object oriented design heuristics, que creo mucho mas relevantes, pero claro, no te explican 'truquitos' o conceptos tan imprecisos, enfocados a que produzcas código sin entender absolutamente nada. Dicho esto, insisto: Uncle Bob es un crack, no estoy diciendo que el autor de ese libro no entienda nada, estoy diciendo que ese libro es adorado por gente que generalmente, no entiende nada, y que eso es consecuencia del público al que está dirigido y la forma en la que está redactado y explicado todo.
Aun así, te he votado positivo por que no querer hacer "clases monstruosas", pese a lo impreciso de todo, al menos muestra interés por producir software mantenible y extensible, que ya es mucho hoy en día
#6 Que meada fuera del tiesto de #3 y lo peor que está muy votada.
¿Compilar a bajo nivel? Ahora me entero que existe esa palabra.
A ver , hoy por hoy si eres fabricante y no eres tonto das todas las especificaciones de tu hardware para que la expriman, no es como los ochenta que había instrucciones ocultas en las CPU.
Es que aunque sea ensamblador, tienes acceso a toda la máquina, no hay trucos (o no debería) hacer trucos rollo demoscene.
Lo único, es el rodaje de las máquinas, que no es lo mismo las décadas, que si que las x86 llevan una eternidad y se sabe como aprovecharlas y sus fallas, y que con ARM hay que volver esa experiencia (que creo que ya hay un % alto) pues si.
#32 Pero estamos hablando de desarrollar para servidor. Ahora AWS tiene instancias ARM.
Obviamente para sistemas empotrados siempre vas a hacer compilación cruzada. Vamos, que yo no me veo desarrollando un microcontrolador AVR desde el propio AVR, por llevarlo a un caso extremo. Pero vamos, que tampoco me veo desarrollando desde un placa raspberry pi nada más grande qu un script en python para leer unos pines GPIO.
Desarrollo en mi portátil x86-64 y compilo donde haga falta. ¿O tu tienes una estación de trabajo ARM en la que puedas trabajar cómodamente, probar en local y luego desplegar a las instancias cloud de testing?
Que ni digo que en el futuro no las tengamos, pero de momento no veo estaciones de trabajo ARM en ninguna parte, aunque en uno de los comentarios del envío hay uno que dice que desarrolla directamente sobre ARM en local.
#59 pues sí, leyendo tus comentarios veo que algo controlas , pero vaya que laccompilación cruzada existe desde los tiempos del Z80, se me hace raro que no conozcas el término.
De hecho si empaquetas blobs para routers, lo que haces es precisamente una compilación cruzada.
#6 conoces poco entonces. #9 está totalmente en lo cierto.
Cross compiling es desarrollar ejecutables en un entorno distinto a nivel arquitectura.
Cada vez que se desarrolla una aplicación de smartphone se debe probar en el mayor número de arquitecturas posibles para garantizar su funcionamiento, porque programas en una máquina con un set de instrucciones totalmente diferente. Hay que emular el procesador y compilar para esa instancia.
Emular un smartphone es relativamente fácil, pero un servidor suele ser más potente que un desktop, por lo que se desarrolla en la misma plataforma que el servidor receptor del código.
Es difícil ver un escenario en el que el desarrollador y el servidor sean ARM, al menos en el futuro inmediato.
#9 Estoy con #6. A que narices te refieres con compilacion cruzada a bajo nivel? Compilacion es compilacion. Cruzada ya se refiere a que estas compilando para una arquitectura y/o procesador diferente.
#37 Urasandi 
, pero vaya que laccompilación cruzada existe desde los tiempos del Z80, se me hace raro que no conozcas el término.