¿Qué tipos de diagramas recomendáis hacer de cara a un proyecto? Conozco de flujo, casos de uso y E/R para DB.
O sea estan pidiendo un fullstack que sepa hacer back tanto en Node como en imagino, Laravel o Symphony, que sepa hacer apps hibridas y que encima tenga que llevar un equipo de 5 personas y como mucho muchisimo van a pagarle 33k XDDD vaya broma
Yo les hago todo eso por 33k, pero en un horquilla de entre mal y bien, aunque mayormente mal porque npi de nada.
#41556 Estamos trabajando en ello, queremos perfeccionar las tecnicas del pan gallego asi que necesito a alguien que sepa de:
- Masas madre
- Pan gallego
- MEAN Stack
- AWS
- AI
- Analisis predictivo.
Salario 2 magdalenas y una hogaza de pan, enviarme el CV por privado.
#41559 pues yo lo digo, busco hacerlo lo maximo func.
Bueno estaré 1 mes más dándole a fp y entonces vendre con las dudas de cpp/rust xdd
#41562 Entonces, quieres un iterador inmutable, y derivas cada uno de los elementos en base a que? al índice? a otro parámetro que necesites en el next? El generador si tiene estado ?
res = iterator.first(isValidResult)
#41563 Te contesto por MP, no quiero seguir con el tema. Tomo nota de las alternativas, me gusta tener la funcion recursiva más que el generador/iterador. El generador tiene de bueno que es lazy/infinito si quieres, el iterador supongo que tendría más performance si me la suda tener todo immutable.
#41536 En Java ni idea de cuánta es la diferencia de performance, pero en JS es notable.
Yo uso map, filter, some, every, reduce y demás, sólo cuando las listas de datos no son muy grandes. En backend, cuando tengo que trabajar con algo más que unos cientos de objetos, tiro de bucles for y a tomar por culo. Lo mismo cuando necesito una carga rápida para algo en front que necesita recorrer una lista excepcionalmente rápido, pero menos a menudo.
Los métodos funcionales me parecen cojonudos para hacer el código legible, pero cuando el rendimiento es prioridad, mejor dejarlos fuera. A menos que, yo que sé, sólo tengas que hacer una única operación simple (como un simple filtrado).
Es que hay que usar las cosas para lo que se inventaron. Putísima manía de algunos de meter con calzador un MapReduce siempre que pueden.
#41568 Sí, claro, en una web o una app híbrida. Desu being desu.
Será que no puede llegar a haber una diferencia abismal entre dos apps de JS que hagan lo mismo xdd.
#41565 has hecho benchmarking o tienes uno a mano con el que poder extrapolar? es que en comparación con el resto de cosas yo no sé cómo de lento es la verdad. Recuerdo leer un artículo que no estaba nada mal sobre el rendimiento de c# que usando no sé qué mierda del CLI en los ejemplos que ponía sacaba rendimiento parecido a c plano (eso sí era una puta mierda de código)
es que en el momento en el que tienes varias peticiones de red no sé hasta qué punto es rentable andar min-maxeando así la verdad, encima la mayoría de benchmarks son para medirse la polla, como lo de las 10k requests de node y todo eso
#41569 pues habría que ver el código. A esos niveles te diría que importa más la complejidad de las funciones que hacer funcional.
Si tienes millones de datos lo mismo necesitas estructuras de datos auxiliares...
La performance ahora enserio pues se nota obvio , però debería ser aceptable y el mayor cambio lo notarás picando buenos algoritmos.
En mi experiencia, he hecho angular un repo con unas 300?? Componentes combinando apis Rest con websockets i manteniendo algo un poxo complejo.. Se lo preguntaré a mi amigo de fb que es de front.
Se que hacen código funcional con reason y mierdas así pweo después se pasa a js puro para que vuele... Eso me parece que no hay que olvidarlo.
El tema de optimizar el web pack, que yo lo he hecho, te aportarà más beneficios que iterativo vs funcional también.
En scala se que el xompilador genera el mismo código en muchas cosas funcionales..
#41570 #41571
Tenéis una web comparativa aquí: https://jsperf.com/simple-js-loop-comparison/2
La diferencia no es muy elevada, pero para algunos casos vale la pena tomar el camino más rápido. Yo en la app con la que estoy ahora, tengo apenas unos poquitos for en unas partes concretas que quiero que tiren rápido, pero bastante limpios y óptimos, así que tampoco afectan a la legibilidad. En el resto, todo funcional, y de lujo oye.
Lo que sí que nunca uso son los whiles. Tengo un do-while en mi app, y porque lo tengo bien testeado y es la forma más cómoda de hacer esa determinada función, pero vaya que es una rareza que los use.
Madre mia no sabes la droga que es el puto JetBrain y sus IDEs hasta que te quedas sin usarlos
Es como ir en bici sin ruedas programar sin JetBrain en serio, si no programais con este ide, mirarlo que es muy facil pillarlos gratis con un correo de estudiante aunque ya cobreis > 2k
Me he pasado 1 semana a puritito visual code y casi me pego un tiro
Que inteligente soy, a saber por qué se me ha ocurrido que era buena idea hacer npm run prod y pushear los cambios a git para ponerlo en production porque mi microserver le cuesta un huevo compilar.
Ahora no puedo hacer npm run prod en el live cuando quiero porque me da problemas obvios de cross-env y tampoco puedo pugar los node_modules/cache por el rollo de que si peta la lio basta.
Regla n1: Nunca hacer nada sin un buen café antes.
