@JuanEnriqueGarcíaSancho Antes que nada Bienvenido. Lenguajes con futuro a largo plazo? C, C++, R, tienen al menos 40 años cada uno y aún se siguen usando. Pero imagino que apuntas a los lenguajes más novedosos, en ese caso es muy difícil saber hacia dónde va ir el mercado.
La IA que mencionas es GPT-3, que apareció creo que el año pasado y realmente hasta ahora parece que es un hito en lo que concierne a IA, pero habrá que ver. La aplicación que mencionas es NLP o procesamiento de lenguaje natural, es una de las disciplinas más complicadas del mundo de la IA.
Lo que entiendo, es que si a lo que apuntas es al área de la ciencia de datos/IA, los lenguajes por excelencia son Python y R. Pero más que aprender un lenguaje en sí, con tu experiencia, no debiera ser difícil aprender uno u otro, el tema es la teoría, yo apuntaría mas que nada a eso.
Quería preguntarte acerca de la seguridad de usar vue y estos frameworks. Tengo un amigo que está empeñado en decir que por el hecho de usar axios (ya que los datos se pueden ver), estos frameworks son inseguros. ¿Es verdad?
@SantiagoCorreaAguirreSanmar Visible por quién? Quieres decir con un sniffer de red? Si el protocolo es https, aunque sea visible va cifrado por lo que sería totalmente seguro
@gbianchi Ya bueno, pero que el cliente pueda ver sus propios datos nunca se ha considerado un riesgo de seguridad
A menos que estemos hablando de que el servidor está guardando "datos sensibles" (secretos del servidor) en el lado cliente, cosa que nunca debería hacer sin cifrar con una clave que sólo el servidor tenga
pero @SantiagoCorreaAguirreSanmar, aclara en qué sentido hablamos aquí de seguridad. Te refieres a la propia conexion TCP entre cliente y servidor? Que pueda ser espiada por un tecero mediante un sniffer?
parece que piensa más bien entonces en que es inseguro porque JS es interpretado y porque el código JS está en el lado cliente, y por tanto cualquera puede verlo
es eso? inseguro porque el código fuente es publico?
Sólo se fía del código propietario cuyo fuente no puede ver? ¡AL revés, hay que desconfiar de ese!
Posiblemente su miedo es que un usuario, usando la consola para ejecutar paso a paso e inspeccionar variables, pueda alterar el valor de alguna de esas y liarla
efectivamente eso es posible, pero el lio sólo afectaría a su propio cliente
si el lío llega a salpicar al servidor, es que el propio servidor estaba programado de forma insegura
repito "seguridad por secretismo", no funciona
El servidor tiene que estar hecho en modo paranoico, pensando que todos los clientes estarán alterando datos para tratar de liársela
por eso debe incorporar verificación de datos, protección frente a inyección, o a falsificación de formularios, etc.
y eso tanto si el cliente tiene acceso al código como si no. Un hacker te puede enviar datos manipulados aún sin acceso al código, por ingeniería inversa
Un usuario puede crear un problema similar sin necesidad de JS, sino a la antigua. Puede examinar el FORM HTML y descubrir la URL a la que hará el POST. Puede crear un cliente python en un par de líneas que haga un POST a esa URL y envíe todas las Cookies necesarias, y los campos del FORM "manipulados"
si el servidor no verifica lo que recibe, porque confía en que el cliente es "tonto" y no sabrá manipular los datos, ya se la habrás liado
Por eso los formularios deben llevar tokens (como CSRF) que son piezas de datos cifradas en el servidor, y que sólo el servidor podrá descifrar, y le permiten verificar que el formulario lo ha creado él, y está asociado con una sesión de usuario particular
> A CSRF token is a unique, secret, unpredictable value that is generated by the server-side application and transmitted to the client in such a way that it is included in a subsequent HTTP request made by the client. When the later request is made, the server-side application validates that the request includes the expected token and rejects the request if the token is missing or invalid.
si, el JWT es un token firmado
para poder verificar que quien lo presenta no lo alteró
Aha, ya lo pillo. El server genera un token aleatorio, lo asocia con la sesión del usuario (o sea, lo almacena en la sesión, en el lado server) y se lo manda con el formulario
ya, pero si puedes deducir el token de la sesión, por ejemplo con un SHA256, eso no sería seguro. El mismo algoritmo puede usar el atacante para deducir también el token a incluir
Hm... no, porque el atacante no tiene el token de sesión
Hm... pero dejemos de lado el ejemplo google analytics, y considera este otro. Un desarrollador hace una página web y en ella usa alguna biblioteca JS porque hace efectos "chulos". Confía en esa biblioteca, pero es "maligna" en realidad y está intentando robar cookies del cliente
El cliente confía en la página que visita, pero no tiene por qué confiar en la miriada de bibliotecas JS que esta usa
si una de esas bibliotecas es maligna ¿no es eso XSS? Al menos de algún tipo (no igual al clásico de inyectar JS en el servidor desde el lado cliente)
@JuanPerez lo mejor que podés hacer es poner la pregunta directo :) yo si veo que alguien pide "una ayuda" nunca voy a decir "si, dale... te ayudo" porque no sé de qué se trata ni cuanto tiempo va a llevar. Si veo la pregunta y es algo rápido (o que puedo apuntar en alguna dirección) respondo :)
por suerte, hay gente mucho más generosa que yo en la comunidad igual :P
Tengo estos registros almacenados y quisiera poder hacer mediante un case o algo donde se rellenen las horas faltantes por cada dia rellenando el total como 0
@JuanPerez uff, es feo... tendrías que usar un cursor (muy feo) o tener una tabla con todas las horas y hacer un left join ponele. Lo más elegante para mi es que la app reciba esto y muestre las horas faltantes como 0
Tengo la siguiente línea de código: edges.append(v_edges[dist_edges.index(min(dist_edges))])
Y me gustaría expresarla de una forma un poco más eficiente o por lo menos no tanto liosa. Estoy tratando de implementar el algoritmo prim en python
La cosa es que esa linea añade la arista de valor mínimo, donde edges representa una lista que contiene TODAS las aristas, v_edges las aristas seleccionadas (las de menor valor) y dist_edges lista con las distancias
Así puede parecerse muy lioso, pero si se ve el código completo, creo que es más fácil ver el propósito (implementar prim con solo una namedtuple de parametro que contiene los nodos)
@JuanPerez sql no puede inventar filas.. tenes que hacer algo mas para que aparezcan las filas que faltan... porque querrias guardar filas sin sentido en la db?
min calcula el mínimo de esa lista, para lo cual irá comparando las tuplas. La comparación comienza por el primer elemento, de modo que en este caso el resultado sería la tupla (0, "d")
finalmente al hacer [1] me quedo con el segundo elemento, o sea "d"
@LearningDeveloper Pues eso es que lo que le pasas a min() por alguna razón está vacío
de todas formas ya te digo que mi enfoque con zip() es más lento que el tuyo. Aunque es verdad que tu enfoque se ve confuso, es más rápido
Tengo una duda con el siguiente código. Y es que no termino de obtener el resultado deseado. El siguiente código creo las aristas que estan sueltas no las añade al arbol y me salta un error de asserto error por eso
El código implementado es el siguiente:
while len(recorrido) != len(points): # Si ambas longitudes fuesen iguales, quiere decir que los nodos de points ya han sido visitados
for arista in arbol_MST.edges: # Empezamos a recorrer el grafo
if arista[0] not in recorrido:
aristas_visitadas.append(arista)
distancia_aristas.append(distance(points[arista[0]], points[arista[1]]))
elif arista[1] not in recorrido:
aristas_visitadas.append(arista)
distancia_aristas.append(distance(points[arista[0]], points[arista[1]]))
El resultado que obtengo es el siguiente: error: your implementation is wrong
Your MST distance = 10.06449510224598
Networkx distance = 3.0
