Para empezar no tengo muy claro que es eso de "desarrollador web" y que sentido tiene categorizar a los desarrolladores simplemente por que el mecanismo de entrega sea web, mobile, desktop o haga aplicaciones por linea de comandos. ¿Hablamos de desarrolladores que tunean un wordpress para una pyme?, ¿o hablamos de desarrolladores de sistemas más complejos que ofrecen una UI web al usuario?. En estas categorías se mezcla todo y no tiene ningún sentido hacer la media y decir "esto es lo que gana un desarrollador web en X" porque en realidad eso de "desarrollador web" es un concepto tan difuso que no dice nada.
Un desarrollador automatiza cosas y programa reglas de negocio, si eso luego se traduce en una web, una app de mobil o lo que sea es sólo un detalle más que tiene que dominar dentro de su profesión, que es desarrollar software, igual que tendrá que dominar mecanismos de persistencia, concurrencia, pruebas automáticas, control de versiones y otras doscientas cosas más.
Vamos que estas estadísticas no valen absolutamente para nada, quien quiera ver lo que se puede ganar en otro pais que busque ofertas concretas que se ajusten a sus conocimientos/experiencia en otros países y compare con lo que te ofrecen aqui, y claro informarse bien de lo que cuesta vivir en ese pais, impuestos etc,etc y con eso si que puedes sacar alguna conclusión de si te compensa o no la aventura. Pero estas cosas, aparte de para que algunos maldigan su suerte, no sirven pa na.
#135 Bueno hombre, en realidad lo importante de lo que dice es que en el trabajo no deberías aprender al mismo tiempo que trabajas sino que deberias aplicar técnicas que domines cuando estés cobrando por desarrollar un proyecto. Se suele usar la metafora del músico, que antes de salir al escenario que es por lo que le paguen tiene que ensayar un buen número de horas previas.
Esto no implica necesariamente que tengas que trabajar 40horas y dedicar otras 20h por tu cuenta, nosotros por ejemplo estamos tratando de dedicar 4 días de la semana a proyectos precisamente para tener el quinto día para poder seguir aprendiendo y por supuesto este día no se lo vamos a facturar a ningún cliente. No creo que sea productivo ni sano dedicar 60h semanales a trabajar, aunque esto depende del ritmo y las ganas de cada cual off course yo en el pasado he dedicado esas y muchas más porque me apetecía hacerlo, pero tampoco es de recibo cobrarle a un cliente por hacer un proyecto con la tecnología X y dedicar parte del tiempo que le estas cobrando precisamente a aprender esa tecnología en la que el cliente supone que eres experto.
Robert martin tiene muchas cosas buenas y a aportado mucho a la comunidad de desarrollo, pero a veces sus planteamientos son muy radicales y hay que tomarlos con calma. Parte de su juego y del "personaje" que ha construido consiste en llamar la atención a través de planteamientos muy radicales en las formas, en el fondo suele tener razón, pero las formas a veces se pasa tres pueblos.
#120 Esas arquitecturas "empresariales" javeras..., mucho se puede hablar sobre eso y poco bueno jeje. Por lo general no son precisamente un ejemplo de buenas practicas OO. No es en la parte de los controladores donde estas arquitecturas tienen el mayor problema, la capa de servicios y los mapeos 1-1 de las clases de la dominio con tablas son un problema bastante más grave, el típico modelo anémico: www.martinfowler.com/bliki/AnemicDomainModel.html
Y el debuger lo carga el diablo, si lo usas mucho algo huele mal, probablemente falten test, es una herramienta para emergencias, si lo usas muy habitualmente es que entonces estas demasiado habitualmente en una emergencia, cuidao con eso que es malo para el corazón :P.
#102 El SRP es un principio de OO referido a clases o modulos. Aunque es muy subjetivo se suele interpretar como "que las clases sólo tengan una razón para cambiar". En tu misma pregunta te estas dando la respuesta: "para una pagina que tiene VARIAS FUNCIONALIDADES....", parece claro que en tu caso ese controlador tiene varias responsabilidades, una por funcionalidad, entendido como varias razones para cambiar, tu controlador deberá cambiar si alguien decide cambiar la funcionalidad x, y o z.
Más que pensar en que motivos tienes para separar las cosas piensa en que motivos tienen esos métodos para estar juntos, desde el punto de vista de la cohesión ¿que comparten esos métodos para que tenga sentido que estén en la misma clase? (siendo los controladores normalmente clases sin estado, es decir, que no comparten nada, sería incluso cuestionable porque hay que hacer una clase con métodos en lugar de simples funciones como controladores, aunque esto puede depender del framework/tecnología que uses que es muy posible que no permita métodos como elementos de primer nivel).
De todas formas el SRP es un principio bastante subjetivo, si por ejemplo tus controladores no hicieran nada más que transformar una request http en una petición a otra u otras clases de tu sistema y transformar la respuesta de esas clases en una respuesta Http entonces se podría argumentar que el controlador sólo tiene la responsabilidad de serializar/deserializar peticiones http y delegar en otras clases de tu sistema la verdadera funcionalidad, y probablemente sería un argumento razonable para tener varios métodos en el mismo controlador.
Eso si, si tienes un controlador con tropecientos métodos y que encima implementa sin delegar en nadie las distintas funcionalidades de tu aplicación, pues entonces no hay que hilar tan fino, eso es un lio de narices claramente mal diseñado.
#57 ¿Y que me quieres decir?, Que lo hayas visto no significa que no sea una barbaridad. Aunque un millón de moscas coman mierda, la mierda sigue siendo mierda.
Esta graciosete, teniendo en cuenta que mi curro consiste entre otras cosas en ir a empresas a ayudarles con desastres de este tipo, se siente uno identificado, me falta la camisa, tengo que buscarme una
#35 Uno de los principios SOLID, el primero, es Single Responsability, que dice algo así como que un clase debería tener una única responsabilidad. 6000 lineas de código en una sóla clase indica que esa clase tiene un montón de responsabilidades y que más que probablemente se pueda dividir en muchas clases con responsabilidades más concretas y mejor definidas.
6000 lineas es una exageración del video, en realidad es una autentica barbaridad, más de 200 0 300 ya deberían poner el foco sobre esa clase para revisar si el diseño es adecuado. Con 6000 lineas no es que este mal diseñada, es que no esta diseñada en absoluto, más bien es código vomitado sobre el teclado.
En 6000 lineas se viola el SRP (single responsability principle) con claridad pero no sólo eso, en tantas lineas da tiempo a violar prácticamente todos los principios de la Orientación a Objetos que se te ocurran (nivel de acoplamiento brutal con seguridad, cohesión ridícula, Open close me da la risa etc,etc). Por supuesto que es siempre evitable llegar a eso.
#169 los podcast de jh jeje, anda que no a llovido desde eso.
No todo el mundo es igual ni esta en la misma situación eso esta claro, lo único que digo es que esta profesión si te gusta lo que haces puede ser muy satisfactoria y ni todo es un camino de rosas ni todo es estar explotado en una consultora. Si me pongo en la situación de alguien que este pensandose en meterse en esta profesión y lea estas cosas, sinceramente se esta llevando una idea que no es realista de la profesión como conjunto. Yo a cualquiera que tenga pasión por el desarrollo le recomendaría sin dudarlo que siguiera adelante, porque además de ser un trabajo apasionante te va a permitir vivir más que dignamente y dedicarte a lo que te gusta, y no me gustaría que alguien con esa pasión se vea desanimado por visiones tan pesimistas y que sólo reflejan una parte, la peor, de esta profesión.
#165 Pues depende de lo que busques, si eres una carnica que vendes tiempo de gente lo que te interesa es comprar ese tiempo lo más barato posible y venderlo lo más caro, es decir pagar lo menos que puedas, luego pides setecientas cosas que en realidad no hacen falta para tener "en cartera" a alguien que puedas mandar a diferentes clientes porque tiene X o Y en su curriculum, aunque luego no tenga ni idea.
Si eres una empresa que hace software, entonces lo que buscas a alguien que sepa hacer software como dios manda. En ese caso más te vale buscar gente capacitada y pagaras lo que tengas que pagar por la persona que necesitas porque sin esas personas no hay software y sin software no hay negocio.
¿Cuantas empresas hay de un tipo y de otro?, pues no lo se, no manejo estadísticas (como ese 90% que te has sacado de la manga) pero lo que si te puedo decir por que lo veo a diario es que a las empresas que están en el segundo grupo les cuesta mucho esfuerzo encontrar gente. Vamos que hay muchas formas de ganarse bien la vida con esta profesión, que es lo único que estoy diciendo.
#161 No se si me contestas a mi o te has equivocado, pero no se donde he dicho que "cualquiera" pueda entrar a programar o que eso sea buena cosa. Precisamente muchas empresas, no carnicas, les cuesta realmente mucho trabajo encontrar gente verdaderamente capacitada.
#155 Se como funcionan las carnicas, que son lo peor de la profesión lo sabemos todos, y que hay alternativas también, no se puede hablar de la "profesión" y decir que todo es una mierda hablando de sólo de un caso particular de empresas.
"¿A quién le va interesar trabajar en un sector que cada vez se paga peor y no tiene un convenio que le protege?"
Cuando leo estas cosas no si es que yo vivo en una realidad paralela, ¿a quién le va a interesar trabajar en un sector que tiene un paro del 0% en un país con un 20% de paro?, ¿a quién le va a interesar trabajar en un sector donde se rifan a los buenos profesionales?, ¿a quién le va a interesar trabajar en un sector donde tus conocimientos son valorados en todo el mundo?, ¿a quién le va a interesar trabajar en un sector donde hay docenas de proyectos apasionantes?, ¿a quién le va a interesar trabajar en un sector en el que puedes hacer gran parte del trabajo desde la comodidad de tu casa?, ¿a quién le va a interesar trabajar en un sector en el que aprendes cosas nuevas día tras día?, y podría seguir un rato largo.
Llevo más de 15 años en este sector, me encanta esta profesión, disfruto con ella, y además me ha permitido ganarme la vida más que dignamente durante todos estos años, ¿y se supone que el problema por lo que esta profesión no le debería interesar a nadie es que no tenemos no se que convenio?, ahhh es verdad, que desgracia de profesión!...
Esta es una profesión cojonuda para el que le apasione, y para el que no, como cualquier otra profesión, un calvario de 8 horas diarias, y ningún convenio va a cambiar eso criaturas.
Aparte de ser bastante mitico por las magnificas y abundantes contestaciones dadas en Stack Overflow, también su libro sobre C# es de lo mejorcito: www.amazon.com/C-Depth-3rd-Jon-Skeet/dp/161729134X/ref=asap_bc?ie=UTF8, muy recomendable para quien quiera no sólo aprender sino profundizar a base de bien en C#.
Lo que desde luego no tiene ningún sentido es reescribir algo que ya esta escrito. Si el problema es que el gestor de paquetes no da las garantías necesarias (básicamente garantizar la accesibilidad y la inmutabilidad de versiones publicadas) la solución no puede pasar por reescribir o hacer copy&paste del código. Hoy copio esta función, mañana aquella otra, pasado otra más y al final termino con una montaña de código a mantener en mi proyecto por que no quiero añadir dependencias, gran idea si señor.
No vendría mal de paso entender porque en la comunidad js existe la tendencia a hacer librerías pequeñas, cuando incluyes una dependencia en js el código de esa librería lo tienes que distribuir junto con tu aplicación, esto en una app cliente js implica que el tamaño de tu aplicación aumenta, así que si hacemos una librería gigantesca con montones de funciones y luego la incluimos solo para usar un par de cosas nos llevamos la librería entera y aumentamos considerablemente el peso de nuestra aplicación. Por eso es tan habitual ver esas micro-librerías en js que pueden resultar chocantes para gente que venga de otros entornos donde realmente añadir un poco más de peso a la aplicación no es tan relevante (sobre todo el entornos servidor).
Vamos, que antes de decir que le problema es que la gente no sabe programar y yo si que soy muy listo, como hace el autor del blog, no vendría mal entender un poco mejor las motivaciones que tuvieron otros programadores para hacer las cosas así.
Cuanto sensacionalismo, luego lees la noticia y resulta que han analizado 700 y pico proyectos en github, analizando errores reportados y los parches que solucionan esos errores. Vamos que para lo único que puede servir es para detectar patrones comunes de error y más que para arreglarlos automaticamente sería util para mostrar avisos de posibles errores si detecta esos patrones o para inferir algunas prácticas que pueden inducir a errores y sacar algún pequeño catalogo de buenas prácticas u olores a evitar.
Hay cientos de herramientas y proyectos de investigación en la misma linea, pero en general las herramientas de analisis estatico como esta tienen un uso bastante limitado, los bugs importantes son los que tienen que ver con la lógica del problema o incluso con no resolver el problema adecuado.
El manifiesto del "handmade dev" no lo conocía pero es una soberana estupidez. Es tomar una sóla de las dimensiones del problema del desarrollo de software, el rendimiento, y ponerla por encima del resto de dimensiones sin tener en cuenta el contexto.
Pobre del que tenga que mantener el codigo que vayan dejando a su paso estos lumbreras. Velocidad de desarrollo, mantenibilidad, extensibilidad, robustez, escalabilidad (que no es lo mismo que rendimiento)... vamos a olvidarnos de estas cosas y a escribir toneladas de código en lenguajes de bajo nivel optimizando chorradas que no le interesan a nadie!, gran idea.
Hoy en día existen lenguajes como Rust o Go que pueden sustituir a C en casi cualquier escenario y están mucho mejor preparados para la programación multihilo. Salvo para sistemas legacy donde no quede más remedio que seguir usando C es difícil pensar un escenario donde iniciar un nuevo proyecto con C tenga sentido la verdad.
El problema desde un punto de vista técnico,sin entrar en valoraciones de posibles sobres y corruptelas varias en las adjudicaciones de proyectos, lo primero que hay que entender es que un proyecto como este no tiene un principio y un fin, el software necesario para gestionar los impuestos de ayuntamiento u otras cuestiones esta en constante evolución, este software se tendrán que mantener y evolucionar mientras exista un ayuntamiento para irlo adaptando a las distintas necesidades, normativas que van cambiando etc,etc. No es un producto cerrado que se pueda externalizar y me lo entreguen en una cajita listo para usar.
Decía alguien que el software es el sistema nervioso de cualquier empresa/administración, si dejamos que el conocimiento de ese sistema nervioso se quede fuera de la organización esa organización siempre estará lastrada porque no podrá aplicar cambios si no es capaz de modificar el software para que los refleje. Es fácil verlo en este caso, entra un equipo de gobierno al ayto y quiere cambiar X e Y en lo que respecta a los impuestos, pues más les vale poder modificar el software que gestiona estos impuestos, porque si no por mucha voluntad politica que tengan para cambiarlo no van a poder hacerlo o lo van a hacer con muchisimo dolor de por medio (dolor que es dinero del contribuyente).
Lo razonable sería construir esto dentro del propio ayto por personal contratado, se pueden contar con ayuda externa para formar estos equipos, ayudarles con buenas practicas, con tecnologías, pero el conocimiento se tiene que quedar dentro de la organización si queremos construir una organización moderna y efectiva que pueda adaptase a los cambios con cintura suficiente. Este camino no es fácil, porque hay que formar al personal existente o contratar personal que tenga la capacidad para llevar proyectos complejos de este tipo, pero hay que empezar a andarlo en algún momento, el camino de la externalización en proyectos que son el core de una administración es, en mi opinión, una barbaridad que tiene que ver con no entender la naturaleza del software y su papel en las organizaciones.
Pues esta vez no se si estoy muy de acuerdo con bonilla, 5000 al mes es una buena facturación para un freelance si tienes pocos gastos, un informático que trabaje en su casa no tiene excesivos gastos salvo los 300 euros de seguridad social, gestoria si no quieres hacer todos los papeleos tu sólo, algo de luz, el equipo informático que muy probablemente tendrías igualmente. Es cuestión de echar cuentas, otra cosa es que tengas muchos gastos por ejemplo en viajes, alojamientos fuera de tu ciudad etc, etc. Entonces los 5000 se te pueden quedar muy cortos.
Más que reglas de brocha gorda lo que hay que hacer es informarse como dios manda de lo que cuesta ser freelance, tener claro cuanto se paga de SS, cuanto se paga de IRPF, cuanto cuesta una gestoria, cuantos gastos vas a tener y si los puedes imputar como gastos (que no siempre es tan facil... esa es otra), tener claro que no todas las horas que trabajes las facturas (reuniones previas, negociaciones, desplazamientos, gestión de papeleos varios).
Al final, como freelance lo que estas haciendo es eliminar un intermediario, así que no se porque debería ser tan extraño que un freelance pida 50 o 60 euros la hora cuando una consultora te cobra eso y más por alquilarte la misma persona, en realidad las empresas ya pagan la hora de "informático" (habría mucho que hablar claro, de la especialización, la experiencia y mil cosas más) a ese precio.
Al final lo más complicado es tener clientes y un flujo de trabajo constante, ahora mismo en este país no somos tantos los freelance y o te haces conocer de algún modo o es difícil que vayan a confiar en un freelance en lugar de acudir a la consultora de turno. Un mercado donde la figura del freelance fuera más habitual y las empresas se habitúen a contratar así es bueno para todos, menos intermediarios que no aportan ningún valor fuera de la ecuación, bueno tanto para los clientes como para los profesionales de este sector, y es facil de constatar mirando como funciona el tema de UK o EEUU por ejemplo.
Pues yo tengo 37 (casi na...) empece a programar a los 15 y profesionalmente a los 20 o 21 no recuerdo exactamente, ahora que parece que por fin empiezo ha hacer cosas medio decentes que no me digan que estoy viejo!, para echarme una carrera lo mismo si, pero para sentarme delante de mi ordenador a programar todavía estoy en forma.
Vamos a ver, esta profesión es tremendamente compleja, hacer software, hasta el más trivial software de gestión, es muy complejo si se quieren hacer las cosas bien y producir algo que no haya que tirar por el retrete en dos años. Yo personalmente si tengo la suerte de que mi experiencia se valora y me puedo seguir dedicando a lo que me gusta y espero que por muchos años más, pero es cierto que la industria tiene un grave problema de hype cronico y se tiende a pensar que alguien joven estará más al día en ciertas tecnologías, aunque esas tecnologías se queden viejas en 2 años y vuelta otra vez a empezar. (cuestión aparte son las carnicas, que esas no hacen software, venden tiempo de gente y trabajan con niveles de calidad irrisorios, no necesitan buenos desarrolladores, necesitan desarrolladores baratos). Hasta que no empecemos a espabilar y darnos cuenta que lo que de verdad define a un desarrollador son las practicas y los fundamentos que se tardan muchos años en adquirir no valoraremos la experiencia como se debe.
De todos modos, siendo optimistas, me da la sensación que los de mi edad estamos justo en la brecha de cierto abismo tecnologico con generaciones pasadas, las cosas están cambiando y cada vez será más habitual encontrar desarrolladores entraditos en años, no es raro en otros paises, Kent Beck, Ron Jeffries o James Gosling no son precisamente chavalines, pero esto es sólo mi sensación, lo mismo en dos años no me contrata nadie, quien sabe.
Como casi siempre, el problema no es la herramienta, los que tienen problemas con el control de versiones no es porque no entiendan git, es porqué no entienden como gestionar las versiones de un proyecto y porqué hacen lo que están haciendo. Lo fundamental no es si uso git, mercurial o svn, lo fundamental es si hago main line development, hago feature branching etc,etc y porqué hago esto en función del tipo de desarrollo y de las necesidades que tengo. No es lo mismo hacer una librería o un producto del que tengo que soportar N versiones vivas al mismo tiempo que desarrollar un sistema en el que sólo tengo viva la ultima versión, tengo que pensar en el balance entre tener ramas y hacer mis integraciones menos frecuentes o tener una única rama y integrar de forma constante, tengo que pensar si tengo o no una estrategia de despliegue continuo y como afecta la politica de ramas a esa estrategia etc,etc.
Luego, cuando uno tiene los conceptos claros y sabe lo que hace y con que objetivos, se trata de elegir la herramienta que mejor implemente las practicas que quiero seguir. Mientras la gente insista en hacer las cosas al revés, elegir primero una herramienta y luego adaptar sus prácticas a lo que permita la herramienta, pues mal asunto, luego nos quejamos de la herramienta porque no hace milagros.
#175 Si, la frase es de un ceporro, y todas las güebs se hacen adaptando un CMS porque es 10 veces más barato, lo que tu digas, no te olvides de comentarselo a gallir para la siguiente versión de meneame por cierto,que mira que hacerlo de cero, un ceporro el tio.
Desisto, tu sigue con tus sobres, tus corruptos y tus cosas, cada loco con su tema.
#171 Por desgracia no es mía la frase porque es bastante buena, pero bueno tu mismo.
Si tu crees que la forma más adecuada de hacer un proyecto como este es coger un CMS y adaptarlo... pues en primer lugar me alegro de que no seas tu el que lo hace que no me apetece que se tire dinero público en más porquerías, y segundo ya espabilaras algún día y lo mismo entiendes de que va esto de desarrollar software, o lo mismo no, que los que hay que no espabilan nunca.
Y insisto, mi discusión es técnica, de politica estás hablando tu sólo.
#168 Hay un dicho antiguo sobre estas herramientas "facilitan el 90% del trabajo a cambio de hacer imposible el 10% restante".
No todo en la vida es coger un CMS y personalizarlo, de hecho esta página no tiene nada de "cms", hacer un desarrollo de mierder chapuceando un CMS hasta que encaje con lo que quieras no sólo puede incluso ser más costoso de desarrollar sino que además va a suponer unos costes de mantenimiento futuros muy superiores y cualquier modificación te va a costar infinitamente más. Repito si estas tratando de experimentar y ver como articular la participación ciudadana a través de software hacer un desarrollo a medida tiene todo el sentido del mundo porque si la idea funciona vas a tener que ir evolucionandolo constatemente, no tiene sentido empezar con un mojon parcheando un CMS que luego no hay quien mantenga ni modifique.
Y no me vengas con chorradas de los mios y los tuyos, yo no soy de nadie, yo doy mi punto de vista en este tema como técnico sin ningún tipo de sesgo político. Después de bucear un poco por el repo y después de haber visto muchos proyectos de la administración te puedo asegurar que este proyecto esta a AÑOS LUZ del nivel de calidad que se suele encontrar. Un repositorio con acceso público (como debería ser cualquier en cualquier proyecto pagado con nuestros impuestos), un código de calidad y con test automáticos a montones y bien escritos (que esto si que es raro de ver), un proyecto que te puedes bajar y poner a funcionar en cuestión de minutos...
Un desarrollador automatiza cosas y programa reglas de negocio, si eso luego se traduce en una web, una app de mobil o lo que sea es sólo un detalle más que tiene que dominar dentro de su profesión, que es desarrollar software, igual que tendrá que dominar mecanismos de persistencia, concurrencia, pruebas automáticas, control de versiones y otras doscientas cosas más.
Vamos que estas estadísticas no valen absolutamente para nada, quien quiera ver lo que se puede ganar en otro pais que busque ofertas concretas que se ajusten a sus conocimientos/experiencia en otros países y compare con lo que te ofrecen aqui, y claro informarse bien de lo que cuesta vivir en ese pais, impuestos etc,etc y con eso si que puedes sacar alguna conclusión de si te compensa o no la aventura. Pero estas cosas, aparte de para que algunos maldigan su suerte, no sirven pa na.