acabo de responder a los HW y no me sale el progress 
¿Por qué crees que implica más redundancia? No digo que no sea así, pero al menos hasta donde yo he podido ver los datos no se repiten más de lo que se repetirían en una base de datos relacional.
En realidad en las bases de datos relacionales puedes tener también toda la redundancia que quieras si las diseñas mal, pero si se hacen bien y al menos has aplicado la tercera forma normal de boyce-codd la redundancia es mínima.
El problema de Mongo es que nos induce a introducir redundancia ya que lo que introducimos en una base de datos relacional en varias tablas (entidades y relaciones), con JSON podemos introducirlo en un sólo documento al no haber restricciones.
Un ejemplo claro que se puso durante la primera semana del curso fueron los tags de noticias o los autores. Si te fijas en cada noticia se repetía el autor, en lugar de estar el autor en otro documento y obtenerlo de el, se repite, y lo mismo pasa con los tags. Se repite la lista de tags en vez de haber otro documentos con tags y referenciarlos.
Eso le da velocidad a Mongo, pero le añade redundancia.
Vale, es que yo a eso no lo considero redundancia (no soy DBA, así que es posible que lo sea).
Es decir, sí, tienes los nombres de autor repetidos, pero en una base de datos SQL con una tabla para los autores, al final tendrías que repetir la referencia al autor de alguna manera, con lo que también sería "redundante".
Para mi es redundante si metes valores repetidos de manera innecesaria, pero dado que tienes que relacionar cada post con su autor, vas a tener que meter en su documento o tabla una referencia al autor, sí o sí. La única diferencia es que en una base de datos relacional meterías un ID de autor y en el ejemplo sugieren meter el nombre, pero tienes que meter un valor que vas a repetir varias veces tanto en un modelo como en el otro.
Un ID ocupa probablemente menos espacio que meter el nombre, pero es igual de redundante.
Bueno aquello es un ejemplo sencillo, yo creo que mas adelante lo haran con ids, mas que nada porque el nombre dificilmente sera unico.
Por cierto veo que han puesto la week 2 pero no hay videos, no van a poner o como va? Es para ir haciendo o esperarse.
Tal y como está hecho el curso la verdad es que es un poco coñazo de seguir. 40 vídeos cuando los primeros 10 los puedes explicar en 3 párrafos y 5 quizzes xD
Yo hoy he cargado el máximo que me deja en un 32 bits: 1,99Gb. He subido una base de datos de 25 columnas (datos personales, medios de contacto, fechas, lo típico) y 2.000.000 millones de registros. Era de 8 millones, pero petó en el primer intento. Pensé que no petaría porque el sistema que tiene monta ficheros de 16,32,64,128,256 y a partir de aquí todos de 512Mb. Pero se ve que cuando en total suman más de 2Gb, peta.
Hoy he estado todo el día en el curro haciendo group, distinct y trasteando con todo tipo de filtros con expresiones regulares. A ver si mi compi que se está haciendo el de DBA me monta un servidor 64 bits en codiciones. Hemos probado en uno de 32 e iba algo más rápido que en mi máquina, pero no mucho más. Y tenéis que formatear el csv a subir en formato UTF-8 porque de lo contrario como encuentre un símbolo raro, ese registro no lo sube (aunque avisa del error).
Ha tardado en cargar el fichero 2 minutos en el servidor linux y 6 minutos en mi w7 de trabajo.
Ya empiezo a pillar soltura. Es bastante fácil, la verdad. Todavía no piloto con los famosos MapReduce y el group que he hecho es lo que un group by de un count(*) en SQL. Llevo ya 5 vídeos de la Week 2. Pero vamos, que como dice #69, es coser y cantar.
Ya he acabado la segunda semana, a la espera de que pongan el homework. Se empieza a poner interesante.
#72 en teoria te puedes apuntar. Simplemente no podrás entregar la primera semana y en vez de llegar al examen con un 50% pues llegaras con algo menos. Ya te se tiene que dar mal el examen para que no saques el 65% necesario para aprovar.
Hay mas gente que no va a entregar la primera semana.
Ya ha salido el homework de la segunda semana.
Me esperaba algo más, se hace en 2 minutos. Da más la chapa ver los videos y hacer los quizes que los deberes :/
Por cierto aver si alguien sabe porqué esto no funciona. Lo pongo en spoiler porque es la solución de una parte del 2.3:
#74 Si funciona.
Has probado a reiniciar el bottle?
Al menos en mi caso me ha tocado reinciarlo para que pille los cambios.
he reiniciado y nada. ¿Quizas sea por mi versión de mongo? 2.0.7
el error en cuestion:
#77
Está bien tabulado. Lo he comprobado con 3 editores de texto diferentes.
#76: Eso es un error de sintaxis de python, revisa las tabulaciones.
PD: A mí me pasó algo parecido alguna vez, vuelve a escribirlo todo en un fichero nuevo y te curas en salud xDD
Tiene que ser de tabulado si o si.
Fijate que te dara error si el tabulado te lo hace como tal y no como espacios en blanco. Todo el fichero tiene que ser igual. Si es por espacios en blanco todo tiene que ser asi.
#69 por eso yo ni lo estoy siguiendo.
Mongo es sota-caballo-rey. La dificultad viene en el diseño no en el manejo... y ni siquiera se necesitan 7389563498 videos para diseñar una buena BD sino algo de sentido común y un buen libro de alguien con experiencia REAL para aprender de sus errores (qué operaciones no usar, cuándo denormalizar, etc.)
Cierto, si en vez de tabular utilizo espacios en blanco funciona.
Me parece increible que el sangrado sea un elemento más del lenguaje. Puede inducir a muchos errores, y más aceptando espacios en blanco y no tabulaciones.
Un punto negativo para Python.
#81: La sintaxis de python a mí me encanta, solo hay que acostumbrarse a ello.
Tanto vídeo para unos ejercicios tan chorras xDD
#81 sí se aceptan tabulaciones. Es una u otra, lo que no puedes es mezclarlas. Aunque yo recomendaré siempre espacios: para mí tabulaciones en código = no-no, sobre todo porque algunos tienen 8 de ancho, otros 4, etc. vamos que no es estándar.
Me juego el culo a que has cogido código con espacios y le has plantado tabulaciones, y como no se corresponden (¿cómo va a saber Python si tu tabulación equivale a 4 u 8 espacios?) pues casca.
Nunca entenderé el argumento de que la indentación como elemento del lenguaje es absurda. Quiero decir: si vas a indentar igualmente, ¿de qué te sirven las llaves? ¿Para que tu indentación pueda estar mal y no definir los bloques bien o confundir la lectura?
En Python, si te equivocas en la indentación tu código no hace lo que debería... ¡y eso es bueno! Obliga a hacer código limpio e indentado de verdad, no a perderte buscando la } que correponde a tu { para ver dónde está el bloque en realidad...
¿Nunca te ha tocado hacer un trabajo con alguien que indenta mal y te has vuelto loco hasta darte cuenta de que debes ignorar su indentación y seguir las llaves? Y no me digas que el auto-formateo de código lo arregla, porque es solucionar un problema que no debería haber estado ahí en un primer momento.
Por no hablar de que escribir {} me lleva demasiado trabajo y es redundante.
En codecademy.com hay un curso de Python por si alguien esta interesado en profundizar más.
Desde luego para la gente que tiene principio de TOC como yo y se pone de los nervios cuando ve según que código es una delicia :3.
Por cierto, ¿alguien tiene por ahí alguna pag o algo con ejercicios de consultas?
#83 Uno que nunca ha tenido que parsear Python xDDD
{}, begin end, (), etc. gusten o no, son terriblemente eficientes a la hora de introducir bloques lexicos. Por que crees que Python tiene statements como nonlocal o global? Por que lambda esta totalmente roto? Una pista, no es por diseo xD
No es que este en contra del tema de los espacios, Haskell y F# lo implementan bien, Coffeescript tres cuartos de lo mismo, pero lo de Python es un desproposito xD Y lo peor es que encima no se aclaran, unos siguen el PEP8, los hipsters indentan con dos espacios, los neckbeards con tabulaciones... xD
Personalmente me ha dado mas quebraderos de cabeza en este sentido que cualquier otro lenguaje. Yo creo que la solucion es algo tipo golang, donde el codigo siempre esta formateado con gofmt y no hay discusiones que valgan.
#85: Sin meterme en lo que cuentas, parsear Python no es habitual (EDIT: al menos que yo sepa :3). Él habla de un uso corriente, y ahí estoy de acuerdo, las llaves son redundantes.
Otra cosa es lo que tu comentas, pero...
PD: Me acabo de partir con lo de "los hipsters identan con dos espacios". Acabo de ir a mi editor hipster (ST2), e indenta con 2 xDDD
Vaya debate habéis empezado. Horas y horas he estado yo con mi jefe de toda la vida con este tema.
En cuanto a la ventaja de usarlas o no, no puedo opinar ya que es la primera vez (Python) que estoy usando la indentación como elemento del lenguaje.
Sin embargo, si la vas a usar (que es en la mayoría de los lenguajes de uso cotidiano), ... QUE TODO EL MUNDO SIGA EL MISMO FORMATO.
Los hay que las llaves o el begin/end lo ponen ya indentado y debajo el código (cosa que odio a muerte). Lo suyo es que el código esté tabulado pero las llaves no! xD
Y luego me pongo también enfermo con el hecho de abrir llave en la misma línea de, por ejemplo un if, o abrirla debajo. Soy más de abrirla debajo, pero con Java me he acostumbrado a abrirla en la misma línea. El tema está en que se use uno u otro.
Hace poco hice referencia al libro "Código limpio". Ahí se dan varias sugerencias. Sin embargo, aunque parece que con los autoformateadores llegó la panacea, yo soy de los que prefiero tirar el código a la antigua, indentando con un manual de estilo y que todo el mundo siga el mismo formato.
Eso sí, la única ventaja que tiene trabajar en equipo y que cada uno tire el código como le venga en gana, es que cuando una función peta, se identifica rápidamente al culpable xddddddddd
No se como lo haceis pero todos los hilos de desarrollo empiezan hablando de una cosa y termina con otra distinta.
PD: yo también uso llaves en una nueva línea.
#87 xDDD
Yo ya estoy curado de espanto. He currado en banca tocando Perl y q/kdb+ y creedme cuando os digo que he visto cosas aterradoras.
Pues que quieres que te diga, el hecho de indentar con espacios me parece una auténtica basura.
Efectivamente he cogido un fichero que utilizaba espacios. A simple vista me ha parecido que utilizaba tabulaciones, así que he utilizado tabulación. Luego ya me he dado cuenta de que eran espacios en blanco, y por eso mi tabulación no funcionaba.
Creo que la única ventaja que puede tener es que el código siempre deberá estar formateado correctamente para que el programa funcione.
Yo generalmente siempre formateo correctamente mis programas, soy bastante maniaco del código limpio, más aún después de haber leído "Clean Code" de Robert C. Martin, pero pienso que las llaves, o los bloques Begin - End son totalmente necesarios. Por varias razones:
1º: Es más eficiente, desde el punto de vista del compilador o intérprete, esperar a que llegue el fin de un bloque, que estar contando espacios para hacer lo mismo.
2º: Cuando necesites utilizar el código de otra persona en tu programa, u otra persona el tuyo, es necesario un reformateo previo, o sino el programa no funcionará.
3º: Es muy propenso a errores, un simple espacio en blanco de más o de menos puede provocar que el programa no funcione, o que funcione inesperadamente.
4º: No hay un standard oficial sobre cómo sangrar el código, sólo tabulaciones o sólo X número de espacios por bloque, e impuesto por el propio compilador.
