#39450 Luego lees el estado del arte y te das cuenta de que unos chinos hicieron un algoritmo que resuelve tu problema y el código está en Git.
#39450 El día que alguien de tu trabajo descubra elasticsearch, kibana y el plugin de ML te vas a quedar sin curro.
#39453 Menos mal que eso es para la gente que se cree que ML es BI con sus regresiones churretosas y sus gráficas vende humos xD
#39454 cada vez que veo a alguien (en OT pasa mucho xd) colgando una gráfica y una línea recta ahí como intentando demostrar algo me dan ganas de quemar cosas
#39453 En mi empresa se hace data science real.
De aeronáutica, aeroespacial... A lo que yo hago. Tenemos patentes, papers y cosas así.
Mis proyectos son una mierda que alguien que sabe lo que hace tarda 1 mes.
Es más rápido consultar a base de datos o buscar en un array si ya lo he buscado antes y si no consultarlo en base de datos? (.net consultando a SharePoint)
#39457 supongo que es mejor buscar por consulta si el dato pueda haber sido modificado a tiempo real, si no es así y tienes un array, buscar en el array.
Postgres - por decir un motor - además de hacer catching de datos, hace catching a los planes de ejecución mientras dura la sesión, así que te penaliza solamente la primera vez cuando tiene que calcularlo.
Si es para el mundo real y no vas al milisegundo (literalmente), tira la query siempre, que los motores incorporan tropecientas optimizaciones para que no haga falta hacer historias. Si el tiempo de ejecución es importante te va a tocar calcular la talla del array en la que te empieza a penalizar más la búsqueda en memoria que la consulta y hacerlo según toque.
#39457 Sabes por qué existen las caches a nivel de applicación no? xD
Lo normal sería guardarlo en un map (bueno en una cache que está respaldada por un map, seguro que para .net hay) y siempre va a ser más rápido que consultar a una BBDD por muchas optimizaciones que tenga esta (a no ser que sea un hashmap y tu función de hash sea una mierda), normalmente la devolución de un dato es del orden de pocos nanosegundos y ninguna BBDD te va a responder en ese tiempo.
Por otro lado lo normal es que te la sude a no ser que estés haciendo 5000 o 10000 consultas por segundo .
de qué es el array? si son cosas que se van a mostrar al usuario como css lo mejor es ir siempre a la base de datos a por ello
Llega el dueño de la empresa, nos pide un análisis megaurgente de unos datos que ni siquiera estaban en la base de datos cargados porque se supone que teníamos un 16% de devoluciones online y había que bajarlo al 5-8%.
Después de una semana y 4 personas trabajando a full resulta que estamos en el 7.7% de devoluciones y ese dato del 16% ha salido de la nada.
#39469 la gente se inventa estadísticas con tal de demostrar algo, y eso lo sabe el 14 % de la gente
Qué os parecen las webs de desafios de programación rollo codingame, codewars etc? Son útiles durante el aprendizaje o mejor invertir el tiempo en otro tipo de actividad?
Y ya que estoy, algún buen libro para aprender android studio? En español o inglés
Grache!
#39474 existen 3 tipos de web
Leetcode, hackerrank.. Para entrevistas
Codeforces... Para programación competitiva
Codewars... Para hacer katas y rompecabezas
Depende de lo que quieras va bien. Si quieres aprender a programat o un lenguaje nuevo Codewars. Algoritmos pues entrevistas, mates avanzadas las competiciones
He tardado 2h en escribir un código que haga esto. (casi 1h para hacer el move y entenderlo bien xd no he seguido ningun tutorial ni nada)
Tengo una clase "ReflectiveState", que básicamente es un State[A], que siempre mapea todo de A -> A.
No sé como llamarla xd.
trait ReflectiveState[A] {
def unit(a: A): ReflectiveState[A]
def map(f: A => A): ReflectiveState[A]
def bind(f: A => ReflectiveState[A]): ReflectiveState[A]
}
Un state[A] en teoría es esto:
trait State[A] {
def unit(a: A): State[A]
def map[B](f: A => B): State[B]
def bind[B](f: A => State[B]): State[B]
}
Entonces tengo una implementación, donde Pacman es un objeto immutable con (x, y, activado:bool)
PacmanState extends ReflectiveState[Pacman]
De una lista de sharepoint por cada registro obtengo un array de ids que hacen referencia a otra tabla.
Entonces por cada iteración de registros me monto una caml query con todos los ids del array de ese registro.
Después teniendo en cuenta una propiedad de cada elemento de ese array los tengo que ir transformándolos en los objetos que necesitamos en la aplicación. (el cual luego se pasa a json y se vuelve a guardar en base de datos)
Toda esta operación se hace una vez al año, y los datos se quieren en json para luego montar la vista en react con los datos tratados de sharepoint.
Mi código optimización 0 (lo único que compruebo es al recorrer el array del registro si una propiedad ya lo he obtenido de esa iteración, podría tener un array general para guardar todos los que cogiera pero dificultaría el mapeo), pero para rayarme la cabeza cuando se va a ejecutar 1 vez al año e igual no hay ni más de 100 registros, pues tirando xD
