.
Design patterns, design principles (tipo SOLID y demás).
Definir un codestyle para el proyecto me parece de lo más importante, y nadie lo hace.
Tener Clean code está bien como principio, pero para mi es más importante el Code simplicity.
La gente se lo flipa a usar herramientas que no son triviales a veces para resolver problemas triviales.
He visto hacer un js decorator con observables, reduces, y mucha parafernalia, para tener un isLoading=true.
Los Paradigmas son importantes..... Nosotros hicimos uno, la programacion RAD DirectX aunque Darren se tumbo en el el porche de casa a fumar marihuana y todo se fue a la mierda...... si hubiese tenido apoyo la verdad que el proyecto era cojonudo.... tenemos el BCB Code Generator que es una Tool que hizo darren para convertir codigo C/C++ en librerias de componentes para C++ Builder..... todo semi-automatizado, le metes los ficheros de codigo y te lo genera con solo pulsar un par de botones...... la verdad que nadie ha hecho nada como eso..... La TDx Library.... se basa en que todo el SDK de DirectX esta en un wrapper que con añadir el componente que sea de cada seccion del SDK ya tienes disponible esa funcionalidad en tu programa sin codear nada.... esto permite que por ejemplo añadiendo un par de componentes de DirectSound con 1 sola linea de codigo ya puedas reproducir sonidos por ejemplo, o hacer streaming o lo que sea ..... y lo mismo para DirectPlay, Direct3D, DirectInput etc
#3JuAn4k4:Design patterns, design principles (tipo SOLID y demás).
El dise;o no es un concepto, es justo lo contrario. En concreto respondiendote lo que siempre digo del tema, los patrones son parches a lenguajes mal dise;ados. (Peter Norvig). Los patrones de dise;o son code smell (Paul Graham).
https://wiki.c2.com/?AreDesignPatternsMissingLanguageFeatures
Algunos conceptos son la sintaxis y la semantica. Expresiones, patrones (edit:https://doc.rust-lang.org/book/ch18-00-patterns.html), asignaciones, alocaciones, identificadores, estatico, dinamico, compilacion, interpretacion, asertion/verifiacion....
No es lo mismo un paradigma que un patron. El paradigma es una clonculsion o propiead intrinsica de un sitema. El patron de dise;o en camibo es algo externo que ponemos encima.
#7 Depende de cada persona y su objetivo. Si quieres encontrar trabajo lo que se busca hoy en dia son perfiles T
En general yo recomiendo a la gente que tenga una idea de bastantes campos a nivel de anchura y luego entre mas en detalle a los campos relacionados con lo que le gusta, su trabajo o lo que queire trabajar.
La forma perfecta para mi es una primide.
En informatica hay muchos campos pero todos comparten la misma estructura o morfologia. Cuanto mas especialista eres en un camp mas en detalle lo conoces y mas a bajo nivel trabajas.
Que base necesita todo programador? Cualquier guia docente universitaria suele cubrir la mayoria.
- Arquitecturas de computadores: cpu, ram, os
- Redes: routers, tcp, ip (los varios niveles que hay desde el fisico al usario no me acuerdo cuales eran)
- Computacion: algoritmica, complejidad, estructuras de datos
- Software/Programacion: compiladores, interpretes, herramientas, librerias
De nuevo, depende del nivel de abstraccion al que quieras llegar, el software/programacion no existe como tal ya que solo es la inginiera y desarrollo sobre las otras ramas.. Pero bueno, yo la consideraria. De la misma forma "redes" tampoco existiria... Por eso pongo el corte 1 nivel por encima al basico/fundamental que se reduciria en computacion y computadores.
Y al final de todo esta la psicologia humana y nuestra asquerosa naturaleza, donde la gente por tener distintos niveles de abstraccion se cree superiores a los demas. Esto es lo que necesita mas trabajo para progresar en la vida.
Sobre formas de aprendizaje, es un tema que en los ultimos meses he leido bastante y yo diria que hay que ir variando entre:
- Aprender de tecnico a caso de uso. Implementar librerias/frameworks/bases de datos/"lenguajes de programacion" de 0.
- Aprender de caso de uso a tecnico. Utilizar distintas librerias/frameworks/bases de datos/... para ver las diferencias y construir software.
Es igual de incomeptente e ignorante el que no sabe utilizar React que el que no lo sabe implementar de 0. (Y obviamente su profesion es hacer react)
El que utiliza Spring o Mongodb y no sabe lo que hacen por dentro.
...
Al final se reduce a entender el porque utilizas las cosas.
yo al menos cuento algo interesante no gilipolleces como tu eondev..... ten cuidado no te muerdas la lengua y te envenenes a ti mismo
#6 Pueden ser un smell de que el lenguaje no este bien definido o le falten funcionalidades,pero no deja de ser importante conocerlos.
Los design patterns no son más que soluciones conocidas a problemas que se repiten, ni más, ni menos. Si los lenguajes aportan soluciones directamente pues mejor, pero no siempre eliges el lenguaje en el que trabajas.
El T shape es la moda, para luego tener un equipo entero completamente autónomo, con especialistas en cada cosa (po, ux, ui, back, ops, sec, qa)
Se habla de devops se habla de devsecops, pero no se habla de PoUxUiBackSecOps...
Como dev, que necesitas saber: Leer documentación, ser capaz de entenderla y ser capaz de aplicarla. Ni más, ni menos.
#12 Sobre lo primero, yo no creo que se deba ense;ar a hacer las cosas mal. Que historicamente durante 20 a;os se haya estado usando y que por tanto hay que conocerlos para entender lo que usas, si. Pero hay que tener claro lo que es y entender que no hay cometer esos errores de nuevo.
Mira frameworks reactivos, react/vue, nosqls, data flows, el paradigma data oriented etc... La nuevas nuevas generaciones estan corrigiendo los errores del pasado (con ideas del mas pasado xd).
Estuve leyendo un articulo de finales de los 90 donde analizaba LISP vs C y el ecosistema de la informatica en esa epoca. En concreto quiero mencionar unos parrafos en los que hablaba sobre la escuela del mit/standford vs la escuela de unix/c. El problema de la teoria (mit/stanford) es querer tenerlo todo perfecto y no avanzas. La escuela de unix le da igual hacer las cosas mal porque intentan desarollar producto. A dia de hoy esto aun lo tenemos presentes con el modelo de startups, el MVP es todo lo que nos interesa, salimos al mercado financiamos otro Q y a seguir iterando el producto. Queremos resultados aunque esten mal y nos traigan problemas (k8s grandisimo ejemplo). Ahora es el deber de la gente que viene por detras arreglar estos problemas con la experienca aprendida no? Y como vamos a mejorar las cosas si aprendemos solo lo que esta mal y no vemos la teoria? Hay que tener ambas cosas en cuenta. El punto de vista ingenieria/tecnico vs el punto de vista negocio/prducto.
Lo segundo, toda la razon, de hecho he puesto lo de la T shape por una conferencia que asisti hace un par de dias lo contaba el ponente... Aunque de nuevo, incluso en estos temas de metodologias agile/scrum... ya estamos evolucionando hacia otras cosas.
Al final para mi estos dos puntos que hemos hablado se resumen en productividad real vs falsa sensacion de productividad (idea que defiendo bastante). Hay que balancear.
Por ultimo coincido en lo tu conclusion, pero mi vision es que para entender y aplicar necesitas conocer bien la base. No conocer los parches ni ser proeficiente en un framework web sin saber como va por dentro. Porque si lo haces en 5 a;os estaras deprecated.
En fin, tema ciclico xd
#13 Si, y no puedo estar más de acuerdo en que todo esto está ya más que trillado en el pasado. Hay libros de hace 50 años que ya hablaban de lo que es hoy el event sourcing y DDD que tan de mods se puso en los últimos años.
Si al final esto es como la ropa, que vuelve lo vintage y se pone de moda.
#14 Lo más perturbador de esto no es que se ponga de moda, es que realmente los masillas de turno creen que es un descubrimiento revolucionario de su blogger favorito.
#14 #15 Bueno en el caso del desarrollo tecnologico tiene que ver con el contexto historico. Por ejemplo los threads, por que se implementaron los de un tipo y no otro? Por las limitaciones de hardware y so que habia. Hoy en dia al no existir esas limitaciones del pasado podemos traer otros tipos (que es lo que se lleva haciendo estos ultimos anios). Lo mismo con otros muchisimos temas.
La evolucion no es cuestion de moda. Son ventanas de oportunidades.
Y la implementacion aunque no sea revolucionaria si requiere trabajo. Cuando salieron los papers en el pasado no habian los sitemas actuales, hay que re adaptar todo y te encuentras con nuevos problemas.
#15 Medium es el Instagram de los devs, pero din fotos claro, que somos muy tímidos. Mucho charlatán suelto y al final la ropa es del Zara
El problema real, para mi, consiste en la reiterada reinvención de la rueda por la que estamos pasando sistemáticamente, gran causa de ello por la alto-corporativización del sector. Sale un Google. Caga 4 mierdas. Se adoptan como "estandar". Todo Dios se especializa con ello. Luego llega Amazon. Caga 4 mierdas nuevas, todo Dios hacia allí.
La tecnologia, la informatica, no inova. Ya no crece. Lo hacen aquellos que la aplican y en su reinvención, generalizan, enmascaran, sobretodo RENOMBRAN y voilá, cagarros por doquier. Eso si, con nuevos nombres. Nueva terminología.
Me flipa leer lo que se lee por este foro... La cantidad de herramientas, frameworks, especificaciones, patrones, que si DDD, que si TDD, que si con Docker con kubernetes con terraform y Gridl, que si... Es una locura.
Y querer estar a TODO ello, raya el requerir conectarse a Matrix. Y es jodido, porque cada vez mas, todos quieren ser Google, y cualquier empresa de 3 al cuarto, te pide basicamente, TODO. ni perfil T ni perfil pollas. TODO.
#9 era broma, a mi me mola escuchar batallitas de peña de la vieja escuela. Por eso te he dado like :/
#19 No se cual es tu caso pero no veo donde esta el problema. En la vida eliges un camino...
Aprendes los fundamentos. (implementas librerías/lees la documentacion y los papers)
Aprendes un framework. (no tienes ni idea de porque usas lo que usas ni como funciona por dentro, reddit, medium y stackoverflow, modas...)
Entonces llegaras a viejo:
Habiendo aprendido fundamentos.
Habiendo aprendido frameworks.
Si has aprendido fundamentos, te sudara la polla los nombres que le pongan a las cosas y tener que cambiar cada a;o de lenguaje o base de datos o lo que sea. Entiendes los pros/cons de cada cambio y la evolucion natural de la tecnologia.
Si has aprendido a usar frameworks, pues has perdido 5 anios de tu vida y ahora no sabes hacer la O. Tienes otra vez la elección de que camino seguir. por que voy a hacer kotlin si java funciona? jeje
Ahora sobre tu comentario original, no veo el problema. Lleva siendo asi toda la vida. Asume responsabilidades personales y se honesto.
#16 Que enlaces quieres? El otro dia te pase unos cuantos. No vas a encontrar ningun enlace magico que te salve la vida y vas a estar a;os constantemente aprendiendo los fundamentos. No hay formula magica.
#22 Es dificil concretar cosas por no decir imposible. La mayoria de conceptos e ideas de la informatica son problemas abiertos y que estan constantemente cambiando.
Por ejemplo a dia de hoy no hay una definicion de lo que es un tipo, los puedes ver y explicar desde varios puntos de vista y todos tienen su lugar. Pero al final no puedes concretar.
Por eso las preguntas tipicas de pajeet, "que es un objeto?" o "que es una interficie?" son una mierda. Son todo preguntas abiertas.
El unico sitio del estilo que me suena que te va a servir es http://wiki.c2.com/ e ir explorando y veras las cosas que te digo.
https://wiki.c2.com/?ObjectOrientedProgramming
A mi en su dia me sirvio para construir un modelo mental bastante bueno de todo lo que habia aprendido mal.
De nuevo, por esto wikipedia y demas paginas son una mierda para temas de informatica. Ve siempre al standard/paper/source y ponlo en contexto.
#24 En fin, que incluso esa wiki hay que cogerla con pinzas y leer fuentes originales.
Lo que recomiendo a la gente es lo que explique por arriba, creas un modelo mental de muchos conceptos e ideas, olvidas todo lo que crees que sabes y los aprendes de nuevo xd
A nivel personal la gente puede hacer lo que le salga de las bolas pero a nivel profesional yo siempre recomiendo lo que creo que es lo mejor y creo que podemos coincidir lo que pasa si te suda la polla tu trabajo durante 20 anios y de ahi mi mensaje.
Ahora mi opinion por si a alguien se la suda:
Yo abandono el hilo aqui, no quiero secuestrarlo, mas en mi podcast.