Portada
mis comunidades
otras secciones
#1:
Manual de fontanería
Sin reciclajes, sin formación continua, sin grandes novedades tecnológicas desde el Siglo XIX. ¡Haz de la fontanería tu profesión!
Paco el plomero. 15° Edición.
Sin reciclajes, sin formación continua, sin grandes novedades tecnológicas desde el Siglo XIX. ¡Haz de la fontanería tu profesión!
Paco el plomero. 15° Edición.
#7:
Clean Code de Robert C. Martin y así serán los de alrededor los que no se arrepientan de que no te lo hayas leído antes
#3:
Recomiendo The Linux Programing Interface. Breve, ameno y perfecto para leer en el metro. Siempre lo llevo en el bolso para leer mientras espero el autobús.
Y si no te gusta puedes usarlo como arma de destrucción masiva, porque es un ladrillo enorme. Si lo llevas en la mochila te sentirás como los hermanos Dalton intentando escapar del penal arrastrando con dificultad la bola atada a sus tobillos.
Y si no te gusta puedes usarlo como arma de destrucción masiva, porque es un ladrillo enorme. Si lo llevas en la mochila te sentirás como los hermanos Dalton intentando escapar del penal arrastrando con dificultad la bola atada a sus tobillos.
#8:
Yo siempre recomendaré "Amstrad CPC6128:Manual del Usuario"
Es el libro con el cual descubrí que los ordenadores molaban más que ir en bici.
Es el libro con el cual descubrí que los ordenadores molaban más que ir en bici.
Comentarios
Manual de fontanería
Sin reciclajes, sin formación continua, sin grandes novedades tecnológicas desde el Siglo XIX. ¡Haz de la fontanería tu profesión!
Paco el plomero. 15° Edición.
#1 Es no has entendido el modelo de negocio, hazte consultor!. Aqui te dejo una presentacion que le hice a mi jefe.
#43 mis dieses
#1 Creo que sé por donde vas
#61 Son obviedades, simplificaciones absurdas y 'truquitos' cuando tienes una cierta experiencia. Y la experiencia la puedes adquirir con tiempo o leyendo libros. Y sabes que pasa? que hay gente que tiene unas aficiones diferentes y de programar solo vive.
Hay gente (lease #1) a la q no le puedes pedir que este todo el dia autoformandose y aun asi son tus compañeros de trabajo, sacan el producto adelante y son necesarios. Y si les puedes dar un libro que les pone todo blanco sobre negro y que dice grandes PRINCIPIOS que pueden hacer que SU codigo, con el que lidias TU sea mas comprensible sera bueno para ti y para ellos.
Si tus compañeros de trabajo no son tan buenos como tu entonces tu labor es hacerlos mejorar, por ellos, por ti y por tu empresa.
#90 Vale, entonces estamos de acuerdo.
Yo no niego la utilidad del libro, pero es un libro que sirve para que la gente que programa sin haber entendido las bases deje de romper o complicar el código de forma innecesaria. Entenderás mi sorpresa cuando la gente dice abiertamente que ese es el libro que desearía haber leído antes. Precisamente un libro que le das a la gente que no tiene bases pero cree saber y no para liarla...
Clean Code de Robert C. Martin y así serán los de alrededor los que no se arrepientan de que no te lo hayas leído antes
#7 A recomendar esto venía yo. Es un imprescindible para todo aquel que trabaje con código, y sobre todo con código compartido en equipo.
#7 #11 #34 Pese a que Uncle Bob es un crack, ese libro es todo obviedades, simplificaciones absurdas y 'truquitos'.
Que la gente presuma de haber leído ese libro, lo recomiende, o considere que 'desearía haberlo leído antes' es una prueba mas de lo en pañales que está aún esta ciencia.
#61 la pena es que lo normal es encontrarse funciones de 300 líneas con 5 parametros de entrada dentro de clases monstruosas. Son obviedades que hace la vida de los demás mucho más fácil.
#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
#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...
#69 ¿Podrías iluminarnos con algo de tu código? ¿Algún repositorio o algo? ¿O eres el clásico tertuliano?
#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.
#71 Como se revisa eso? Incluso el mismo que lo ha escrito, como puede identificar lo que hace.
A mi me pasan eso o paso el marrron a otra persona en pla hijo puta o miro que función tenia eso y lo reescribo de 0. Seguramente seria mejor que intentar saber que es eso.
#71 he tenido entonces mucha suerte en mi vida laboral,uuuf, 2000 líneas en una función, jajajajaja. Cómo mantienes eso! Y ya flipa si lo tiene que hacer otra persona.
No digo nada de revisión por que evidentemente eso no ha podido ser revisado.
#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.
#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.
#71 He visto un programa cuyo listado no lo levantaba una persona sin ayuda. En producción.
Su mantenimiento (pues era insustituible ya que nadie sabía lo que hacía) era todo un arte.
#64 y con comentarios que son obviamente de cuando esa función tenía solo dos parámetros.
#61 Los comentarios de esta web están llenos de gente que está de vuelta de todo, macho, qué asquito.
#75 eso que escribes no es precisamente lo que escribiría alguien que "está de vuelta de todo"?
Has creado un comentario recursivo
#61 "es una prueba mas de lo en pañales que está aún esta ciencia. "
O de lo sobrado que te crees tú.
#81 eso depende de la definición de sobrado.
Eso depende enteramente de lo que consideres que significa que alguien se "cree sobrado". Como no puedo adivinar a que te refieres con algo tan indefinido como 'ir de sobrado', te explico mi postura y tu decides si el caso es que la programación está en pañales, o es que yo soy me creo un sobrado, o quizás las dos cosas.
En primer lugar, el propio autor define su obra como:
The mission of this series is to improve the state of the art of software craftsmanship
sacado de la primera página después de la portada. Es decir, el mismo reconoce que esto va de "artesanía". No es un libro de software engineering, ni de principios de la informática. Es un libro de "artesania". Dentro del libro se habla de cosas como que las funciones sean "cortas" o que hagan una sola cosa (aunque no definen claramente que significa eso, de una manera objetiva y medible).
Todo el libro es una oda a la "intuición" y los "truquitos". Si bien no tengo nada en contra de ello, no es mas que un recopilatorio de "aprendizajes" de un señor que ha programado mucho, y desde luego es un experto. Fíjate que Robert C. Martin si entiende muy bien los fundamentos conceptuales que existen detrás de sus consejos simplificados y sus "truquitos", pero ese tipo de explicaciones no las vas a encontrar en clean code. Las vas a encontrar en otras obras mas conceptuales.
Yo no tengo nada en contra de Robert C. Martin, al cual considero un gran programador y un gran ingeniero, y tampoco tengo nada en contra de hacer un libro recolectando todo tipo de truquitos básicos de la industria que simplifican y proporcionan estrategias y mecanismos para poder realizar ciertas tareas sin entender lo que se está haciendo.
Sin embargo, el primer ordenador del mundo se creó en el 36. Las ciencias de la computación se apoyan en matemáticas que tienen siglos y los fundamentos en los que se basa la programación tienen también siglos. Pues bien, tras tantos años los programas informáticos se siguen programando de forma desastrosa y la gente necesita que Robert C. Martin le explique que tiene que crear códigos cortos conectados entre si que crean codigos mas complejos, que conectandos entre si crean otros mas complejos, que conectados entre si crean programas completos. Y que al hacerlo así, todo es mucho mas fácil.
Es triste. Si entender cosas tan básicas como esa me hace un sobrado, debo ser un sobrado. ¿Lo que yo pienso? Que no tengo ni puta idea. Que las estructuras conceptuales que construyen un programa moderno son de tal complejidad que razonar sobre ellas escapa a mis posiblidades y a las de casi nadie, y que tardaremos aun años en crear las abstracciones y herramientas necesarias para que todo esto mejore lo suficiente como para poder cubrir las necesidades de digitalización de la humanidad.
Pero aunque soy consciente de la complejidad, entiende que me asombre cuando abro meneame y veo que el libro revelador es precisamente un libro lleno de dibujos que te trata como a un niño pequeño y te explica de manera simplificada hasta el absurdo la forma en la que principalmente no tienes que hacer tus programas, basandose en ejemplos inespecificos y con comparaciones culturales.
Pero bueno, en el resto de ciencias lo normal es exigir un mínimo de rigor, en esta ciencia lo normal es comprar libros de instrucciones para intentar atajar, y poder crear sin entender nada. Y es normal, como digo las necesidades de digitalización son tan fuertes que empujan a esto. Es el mercado amigo.
#82 estoy de acuerdo que casi es un libro que no debería hacer falta, pero sin embargo mis experiencias personales me dicen todo lo contrario y es un libro que recomendaría a la mayoria de programadores que he tenido alrededor. Son conceptos (y truquitos, sí) básicos que todo programador deberia conocer para no escribir auténticos tronchos infumables.
#82 Igual es que no has entendido que no es una ciencia sino una INGENIERIA.
Se trata de ingeniar soluciones para resolver problemas de la gente, no de pajearse con matematicas.
#95
Creo que estás muy perdido.
Decir que la informática no es una ciencia sino una ingeniería es absurdo e ignorante. La informática es todo el campo de estudio relacionado con el uso, aplicación y construcción de computadoras. Dentro de ese campo tan grande, hay varias ciencias, principalmente la física y las matemáticas, creando un campo llamado "ciencias de la computación" que es muchas cosas, pero principalmente es el estudio científico de las computadoras.
Además de las ciencias, la informática incluye también la ingeniería, que emerge como resultado de aplicar la informática. La ingeniería informática estudia la computación aplicada. Dentro de la ingeniería hay muchas disciplinas.
Como te veo muy perdido, te recomiendo mirar este video, aquí lo explica todo muy bien.
Por cierto, sobre lo de pajearse con matemáticas... yo trabajo de ingeniero. Me pagan por problemas relacionados con la aplicación de la informática. Pero creo que tu aún no te has dado cuenta que para resolver problemas de la gente necesitas entender ciencias de la computación.
Leyéndote entiendo el éxito de libros como el de Uncle Bob.
#97 yo creo que el perdido eres tu:
Vivimos de solucionar problemas y eso es lo que hacemos como ingenieros.
Y la ingenieria depende del INGENIO y la ciencia solo marca los limites.
Porque recomiendo ese libro a gente? porque se que les va a ayudar y esta escrito de manera muy amena.
Porque quiero que mejoren
Porque me encanta lo que hago, soy buen compañero y en lo que pueda les ayudare.
Porque no soy un sobrado.
#100
vamos a ver, la ciencia no solo marca los limites, marca el camino. Tú, como ingeniero usas las piezas que la ciencia te proporciona, y si no conoces la ciencia por que les llamas 'pajas mentales matemáticas', dificilmente ingenierizarás soluciones que tengan sentido o sean óptimas.
Y todo ese rollo del "quiero que mejoren", "soy buen compañero" "en lo que pueda les ayudaré" parece que te lo has sacado de un curso de agilismo mal entendido, de esos en los que solo se habla de psicología barata y de energías que fluyen. No entiendo que tiene que ver el team building o la relación con tus compañeros en todo esto.
Clean code es un libro de ingenieria escrito intentando no hablar de ciencia. Está hecho para todas esas personas que no saben nada de ciencias de la computación y si en el libro aparecen depende que notaciones o conceptos, no van a comprarlo ni entenderlo. Es un libro para torpes y podría llamarse "engineering for dummies", de hecho, yo creo que está inspirado en aquellos libros 'for dummies' de los 90.
Me acabo de bajar el pdf, y por ejemplo, habla de que le pongas a las variables nombres descriptivos, que programes en la capa que toca, y que reduzcas el acoplamiento. Todo cosas básicas y obvias, de las que tampoco explica el trasfondo ni la teoría detrás de ello. Es un libro de instrucciones sin el "por que" de nada.
Yo nunca he dicho en todo el hilo que el autor sea un ignorante: no lo es. Tampoco he dicho que el libro sea inutil: no lo es. Me he limitado a decir la verdad, es triste y una pena que a día de hoy sigan siendo necesarios manuales de instrucciones para toda la gente que no tiene ni ideas de ciencias de la computación y que cree que las matemáticas son pajas mentales. Pero es lo que hay, por que como hay pocos ingenieros, pues entra todo tipo de gente a esta industria.
#97 Aunque soy de los que piensa como tu (que es necesario abstraerse hasta conceptos cuando lees definiciones o conclusiones para poder aplicar esos conceptos de forma multidisciplinar y correcta) creo que te has colado un poco.
La ciencia solo busca herramientas y la ingenieria las aplica. Un ingeniero no tiene que saber como se descubre la herramienta, si no que existe, funciona, y por que funciona.
Saber como se descubren las herramientas es util. Pero la mayoria de gente no son capaces de poder profundizar tan alla sobre el por que existe nuestra ciencia. En su trabajo, lo que deben dedicarse es a poder montar los puzzles requeridos para resolver un problema, y montarlos de una manera eficiente y mantenible.
Cualquiera que lea el libro de Clean Code sacara conocmiento. Aquellos que vemos y pensamos mas alla tambien sacaremos mas conocimientos. Y aquellos que simplemente piensen "esto funciona" sacaran lo justo para mejorar su codigo, asi que aprenderan. Por eso es un libro tan bueno.
¿Que alguien que sepa clean code no lo hace mejor programador? Temo que tengo que discrepar. Nosotros valoramos los resultados. No los caminos. Si una persona llega a buenos resultados y sabe que tiene que aplicar y tiene un autor de referencia me parece suficientemente bueno. Que una persona con mas capacidad pueda explicarte eso a un nivel mayor esta genial. Pero ambos son igual de buenos programadores.
#95 mmm, tienes "computer's science" y "computers engineering", así que diría, que sí, que sí es una ciencia además de una parte de ingeniería.
Además, en una ingeniería también debes seguir una serie de formas concretas para resolver los problemas, no lo haces como quieras.
#118
La ciencia solo busca herramientas y la ingenieria las aplica. Un ingeniero no tiene que saber como se descubre la herramienta, si no que existe, funciona, y por que funciona.
La ciencia no busca herramientas, busca conocimiento en forma de predicciones y explicaciones comprobables. La ingeniería construye herramientas en base a esas explicaciones y predicciones y en base a las herramientas que otros ya han creado en base también a esas mismas predicciones y explicaciones. Para dudas, ver:
https://en.wikipedia.org/wiki/Science
Primer párrafo:
Science (from the Latin word scientia, meaning "knowledge")[1] is a systematic enterprise that builds and organizes knowledge in the form of testable explanations and predictions about the universe.[2][a]
Entonces, un ingeniero es básicamente una persona que tiene que construir una solución. En la medida en la que el ingeniero entienda la ciencia, mas herramientas tendrá para construir sus soluciones. Cuanto mas ignore la ciencia, menos herramientas tendrá. Nadie conoce toda la ciencia o ninguna parte de la ciencia. Todos los ingenieros están en un espectro entre un hipotético desconocimiento total de la ciencia, y un hipotético e imposible entendimiento completo y absoluto de la naturaleza.
En este hilo sin ir mas lejos en #95 puedes leer como un supuesto ingeniero, típico lector de clean code, llama a las ciencias de la computación sobre las que se sostiene el libro, "pajas mentales matemáticas". Ya te puedes imaginar el tipo de soluciones que se pueden alcanzar desde esa perspectiva. Creo que ejemplifica perfectamente mis sentimientos sobre ese libro.
Saber como se descubren las herramientas es util. Pero la mayoria de gente no son capaces de poder profundizar tan alla sobre el por que existe nuestra ciencia. En su trabajo, lo que deben dedicarse es a poder montar los puzzles requeridos para resolver un problema, y montarlos de una manera eficiente y mantenible.
Cuanto menos entiendas ciencias de la computación, menos vas a poder realizar predicciones y conjeturas sobre las propiedades de un código para una computadora y para un humano. La ciencia estudia que hace que las cosas sean mantenibles, extensibles, escalables o fiables, y proporciona modelos mentales para que luego un ingeniero, con esos modelos, monte los puzzles. Si el ingeniero llama a esos modelos pajas mentales matemáticas y prefiere leerse un manual de instrucciones para, literalmente leído en este hilo "ser buen compañero", en lugar de "hacerse pajas mentales", ya te puedes imaginar el sistema que va a construir.
Eso no significa que necesites entender toda la ciencia para poder construir soluciones industrialmente válidas o viables, pero tampoco significa que puedas ignorar toda la ciencia y construirlas. Como digo, todo ingeniero está en un espectro intermedio, pero entender eso es vital, no engañarse y pensar que podemos crear un señor que resuelve puzzles de puta madre, en base a unos truquitos.
Cualquiera que lea el libro de Clean Code sacara conocmiento. Aquellos que vemos y pensamos mas alla tambien sacaremos mas conocimientos. Y aquellos que simplemente piensen "esto funciona" sacaran lo justo para mejorar su codigo, asi que aprenderan. Por eso es un libro tan bueno.
De cualquier conjunto de datos se puede extraer conocimiento dada suficiente capacidad cognitiva, siempre y cuando los datos no sean aleatorios (si es que eso es posible, que sean aleatorios, pero eso es otro debate). Yo no niego que ese libro pueda ser útil. Niego que su utilidad ses relevante como para ser mencionado como obra "que desearía haber leído antes". Eso lo entendería de otras obras, pero no de esta, pese a que reconozco que obviamente contiene conocimiento.
¿Que alguien que sepa clean code no lo hace mejor programador? Temo que tengo que discrepar. Nosotros valoramos los resultados. No los caminos. Si una persona llega a buenos resultados y sabe que tiene que aplicar y tiene un autor de referencia me parece suficientemente bueno. Que una persona con mas capacidad pueda explicarte eso a un nivel mayor esta genial. Pero ambos son igual de buenos programadores.
Me temo que discrepamos. Un programador es mejor o peor en la medida en la que es capaz de generar sistemas que cumplan con los requisitos a al menor coste posible. Y en mi experiencia, las personas no son capaces de mejorar en ese aspecto tras leer clean code, o al menos no de una forma substancial. Una persona que creaba código de mierda, lo sigue creando después de leer clean code, simplemente su código ahora está partido en trozos, que normalmente además estarán mal escogidos y será peor que si no lo hubiese partido. Una maraña conceptual es una maraña conceptual en uno o en 20 ficheros.
Si tu consideras que una persona es capaz de crear sistemas que cumplen los requisitos, a un coste menor después de leer clean code, estoy interesado en entender mejor el mecanismo.
#7 Por recomendarlo te has ganado un positivo.
#7 Los que están alrededor se han leído esto:
#16 Otro de la serie:
#30 si tu código requiere comentarios, muy bien hecho no está
#84 Ahá. Por curiosidad, ¿cuánto código de simulación de fluidos has visto?
Porque como no te citen los papers y te informen de las simplificaciones de las fórmulas estás que lo deduces todo en el momento...
Qué curiosa costumbre tiene la gente de pensar que las reglas que aplican a un código apliquen a todos... Cómo si tuviera algo que ver el código de un backend de una web que te haces en tu casa con el código de un driver que hace gente que está en tres husos horarios distintos...
#16 La continuacion esta muy bien
#7 Un libro muy como chulo, sí señor. Aunque todos los ejemplos son en Java, son perfectamente aplicables a cualquier otro lenguaje.
#14 Goto #7
#35 es que yo he venido a hablar de mi libro
Recomiendo The Linux Programing Interface. Breve, ameno y perfecto para leer en el metro. Siempre lo llevo en el bolso para leer mientras espero el autobús.
Y si no te gusta puedes usarlo como arma de destrucción masiva, porque es un ladrillo enorme. Si lo llevas en la mochila te sentirás como los hermanos Dalton intentando escapar del penal arrastrando con dificultad la bola atada a sus tobillos.
#3 Y Ahora fuera de coñas, recomiendo "Algoritmos + Estructuras de datos = programas" para un nivel relativamente introductorio y "Programming Perl", (el libro del camello), para echar unas risas.
#5 Si quieres leer sobre algoritmia y complejidad, nada mejor que tirar de Kennett Rossen, Joseph Stallings, y sobre todo el referente patrio, Luis Joyanes, muy bueno en estructuras de datos.
En mi opinión no hacen falta libros nuevos, sino textos Consolidados, de los que cada detalle ha sido pulido a lo largo de los años.
#5 Yo recomiendo la guía Norton de ensamblador para 8086 , la joya de la corona
#5 Lástima de Perl, con lo versátil que es y en qué se está quedando...
#80 Claro que es versátil, nunca comprueba nada, vale todo.
#5 Me tragué el Wirth a la sombra de un árbol en vacaciones. Perl justo después de eso debe de ser lo más horrible imaginable.
Yo siempre recomendaré "Amstrad CPC6128:Manual del Usuario"
Es el libro con el cual descubrí que los ordenadores molaban más que ir en bici.
#8 date cuenta que el otro día cenando en casa de mis padres me dio por explorar mi vieja librería y ahí estaba
#17 guárdalo como oro en paño, ya es un clásico cotizado en ebay.Yo tb lo tengo en la vieja librería.
#8 esos libros eran auténticas joyas, te enseñaban programación a alto y bajo nivel, y como hacían funcionar el hardware llegando a temas de electrónica. Al menos los que tuve de ZX Spectrum eran así.
Huid del libro del dragón, el de los compiladores. Es uno de esos libros que todo el mundo recomienda pero a la hora de la verdad no se lo ha leído nadie. Cómo libro de referencia el mejor pero para leer evitadlo.
#33 No le conozco, pero de los dinosaurios (el segundo) en cambio es bastante recomendable.
#33 Salvo que curses (y pretendas aprobar) la asignatura de compiladores. Entonces los vas a leer sí o sí.
#47 Que asco de asignatura por dios.
#33 "Compilers: Principles, Techniques, and Tools" es el quijote de la computacion!
#33 222,22$ en Amazon.com
Yo cuando estudiaba me hubiese conformado con un profe.
Lo que teníamos era el típico licenciado con 4 años currando, que venía a clase con 2 pdfs de mierda que no nos compartía, se pasaba la clase haciendo el ultimo ejercicio de deberes sin corregir nada, luego te daba fecha para exámen y se lo inventaba todo. Lo que te pueda enseñar un inútil de esos es lo mismo que puedes sacarte de la "lista de 100 consejos para programar bien" y los ejercicios son los mismos vayas a una privada que a una pública. Los mismos putos ejercicios de mates que han usado durante los ultimos 40 años.
Lo único que va a hacer un profe de programación es corregir examenes dos veces por trimestre.
Ojalá hubiese empezado por mi cuenta con libros y alguna buena página web en lugar de tirar el dinero y mi tiempo.
#23 No ha cambiado mucho..
#23 si quieres aprender leete un libro, pero si quieres conseguir un trabajo necesitas para el 98% de los puestos un titulo.
#36 Completamente de acuerdo.
Lo que digo es que es mejor aprender por cuenta propia y luego hacer los cursos.
#36 En informática no, es de las pocas ramas donde puedes hacer valer tu talento sin titulitis.
#42 estan avanzando pero no llega ni al 5% de empresas que te cogen sin titulo.
Solo starups o empresas rollo google donde ya has demostrado que eres un genio.
Sino el camino mas facil es tener un titulo, puede ser que sin titulo te cojan pero no es lo normal
#36 no es así. Los mejores developers que conozco son alto nivel y ninguno estudio programación
#23 Bueno, luego tienes el típico profesor que lleva 40 años dando clase, enseñando con fortran o delphi, se niega a renovarse y te viola con estupideces que no existen en el mercado hace 20 años.
Hay de todo.
Ya los he pirateado todos. Vale con eso no?
#2 No. Supuestamente hay que leerlos y comprenderlos.
#4 Exacto, igual que el listín de teléfonos.
#2 También hay que leérselos
#2 Léete por encima el siguiente y ya está:
#20 El mejor libro y más útil de todos. Ciertamente una lectura obligatoria.
#20 y si ese falla pues no queda otra que esto
#2 Depende, ¿quieres aprender a programar o tienes contactos y quieres un máster?
SI NO SABES PROGRAMAR
NO SABES INFORMÁTICA
#15 ¿Qué es la informática?
Es más, ¿Qué es el termino despectivo "informático"?
#22 Aqui tienes una introduccion
#22 el arte de echarle la culpa a otro
#53 Al programador anterior, igual que hacen los gobiernos.
#15 tanto años usando el ordenador y nada ... pues sinó se informatica dejala ahi, ningun interes por aprender eso ... y es lo que piensa hoy 2019 la mayoria, ya se que en los 80s, 90s, era otra cosa pero como se ha desarrollado esto y se vio en que consistia ...
#15 Pues viendo la cantidad de programadores que no saben programar, pues como que de informática tal cual...
La informática y la programación son dos cosas distintas. Es como la electricidad y la electrónica, no son lo mismo ni por asomo aunque sus principios si lo sean.
Salu2
#31 #15 se refiere a un anuncio de tv de hace unos años, CCC era?
#37
#37 ¡Ostras perdón! No me acordaba de él, no dije nada.
Salu2
#15 pero saber programar no te hace informático desgraciadamente.
#15 Curso IBM en fascículos.
Son libros supertochos y algunos son estilo diccionarios, simplemente para tenerlos y buscar. ¿Alguno os habeis leido el diccionario completo?. No verdad.
El asunto es sacar patrones de lo que repiten todos ellos y presentarlos como una especie de infografia al estilo de las que hace Dominic Walliman en su canal Domain of Science
Mapa de la Ciencias de la Computación
(Map of computer sciene)
Despues se pueden hacer para los distintos dominios dentro de la ciencia de la computación una especie de infografia equivalente. Por ejemplo una infografia equivalente para algunos de los libros.
Hay que imaginar esto como una espiral que empieza desde un punto central y va aumentado. Despues tomas la linea de la espiral como el camino completo que supuestamente tendrias que hacer. En las primeras vueltas centrales de la espiral está todo lo que es comun a todo, lo que son las bases de todo, y despues segun avanzas por la espiral vas aumentando lo que necesitas saber. Pero para comprender partes del camino de la espiral de fuera tienes que haber comprendido partes de la espiral de mas adentro.
#56 genial el video, no lo conocía
#56 ¿Alguno os habeis leido el diccionario completo?. No verdad.
Habla por ti.
Uno y sólo uno. El clean code de Robert Martin. Ningún libro me ha influido más en mi vida profesional. Encima útil para programadores tanto de C como de java script.
#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.
#85 basicamente, en mi opinión, es la base de todo un código limpio y estructurado.
Mantenimiento y escalabilidad. Sólo con esto ya no harían falta más razones.
Ayuda para desarrollar código más eficiente.
No duplicas código.
Es mucho más fácil seguir tu diseño.
Facilidad de reconocimiento de patrones de diseño.
Coverage de test unitarios.
Revisiones de código eficientes.
Amistad con los compañeros de trabajo.
Seguro que me dejo más razones.
Las funciones son los ladrillos de un programa ¿te imaginas construir un rascacielos con ladrillos del tamaño de coches? Para mi si una funcion tiene más de 20 líneas ya me hace pensar que estoy haciendo algo mal.
#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.
#94 bueno, a mi en la carrera no me enseñaron eso, también es que soy teleco, también te digo que he conocido y conozco unos cuantos ingenieros informáticos que tampoco lo dieron o se les ha olvidado. Yo creo que seremos esa gente que no tuvo la suerte que le hicieran tanto incapie en esos temas y como tú has dicho, son básicos, así que por eso nos ha influido tanto.
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.
#99
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.
Qué abuso de precios. Y al autor le llegará un par de euros de cada ejemplar.
1. https://web.mit.edu/alexmv/6.037/sicp.pdf
2. http://learnyouahaskell.com/chapters
3. https://www.braveclojure.com/clojure-for-the-brave-and-true/
El mejor de todos
Designing with Web Standards de Jeffrey Zeldman
https://www.amazon.co.uk/Designing-Web-Standards-Jeffrey-Zeldman/dp/0735712018
https://www.amazon.es/Dise%C3%B1o-estandares-web-Diseno-Creatividad/dp/8441516081
El mejor libro sobre web que leí nunca, ameno, divertido y útil. Lástima que a estas alturas esté totalmente desfasado.
Salen algunos autores clásicos de la informática como Cormen, Silberschatz o Aho. A esos habría que añadir alguno de Tannenbaum, Stallings o el tío Bob.
The Phoenix Project.
No es de programación en sí, pero es bueno para entender como debe funcionar una empresa que produce su propio software.
#12 ha si me puse yo despues de leerlo
big Data, little penis
Buena lista, me permito ampliar:
Independientemente de tu lenguaje de programación.
* Beautiful Code
* The pragmatic programmer
* The art of Unix programming
* Programming Pearls
* Peopleware
* The C programming language
Interesante porque yo estoy aprendiendo a programar para hacer apps y una web
#57 Head-First Desing Patterns (este es mas POO)
Test-Driven Development de Kent Beck
Clean code de Robert C martin
#92 gracias por molestarte amigo
#98 Me parecen muy buenos libros los 3.
El de TDD te enseña una metodologia de trabajo, que es algo util y transversal a todas las tecnologias, el de codigo limpio te da unos principios y unos conceptos muy buenos y el otro es una manera muy afable de entender los patrones de diseño en programacion orientada a objetos.
Ademas son muy amenos. Lo unico es que creo que solo estan en ingles (el de codigo limpio tb en castellano)... pero aprender a leer ingles tambien te sera muy util
Algún buen libro sobre cómo estructurar bien el código?
#67 https://www.google.com/search?q=Algún+buen+libro+sobre+cómo+estructurar+bien+el+código%
#67 La escuela de la vida
Qué hace esto en portada?
#18 tranquilo menéame es un camello cumplidor, pronto habrá alguna noticia que te dé la dosis diaria de "indignación por politico que hace lo que le venga en gana y yo no puedo hacer nada, tan solo escribir en un foro irrelevante políticamente hablando"
#18 Este es el principal problema de menéame. Los usuarios menean mierdas que no interesan a nadie.
#39 #18 En meneame no hay usuarios, casi todos son clones de la organización (o de organizaciónes). Solo "ayudas" a la portada si te unes, pero lo que sale en portada lo deciden principalmente 3, como el ibex3 (lo del ibex 3 es de "El reino" (2018) que yo pensaba que era "el reino" por el rey y la monarquia, pero se refiere mas al concepto de reino de taifas)
#18 Llegar a portada cada vez cuesta menos y menos. No le doy ni dos años de vida a esta web. (previsión seria).
Yo sigo aquí solamente por nostalgia. De verdad. No es por coleccionar strikes.