En ese caso mi consejo es que no te líes con Ruby, Rails y demás y ve directo a SQL. Ya tienes bastante con la inevitable tarea de tener que explicarles álgebra relacional. Al principio te odiarán un poco pero se pondrán muy felices y te estarán eternamente agradecidos cuando les enseñes que desde Excel pueden ejecutar un SELECT y el resultado verlo dentro en una planilla.
1/2 de :-) El 10/02/2010, a las 22:41, José Luis Torre Hernández escribió: > Hola a todos: > > Lo que pretendo no es formar personas que sepan programar (estaría genial que > esto se hiciera en los primeros años de la enseñanza...) lo que me gustaría > es disponer de una herramienta como AWK (lenguaje que puede enseñarse en un > par de horas y que permite el tratamiento secuencial de ficheros de texto, y > más...) pero que trabajara bases de datos relacionales. ¿Existe algo similar? > > Saludos > José Luis Torre > www.ehu.es > > > El 10 de febrero de 2010 20:27, lasizoillo <lasizoi...@gmail.com> escribió: > El día 10 de febrero de 2010 17:18, d1d4c <d1...@aktivix.org> escribió: > > Saludos. > > > > Kortatu escribió: > >> > >> Si sirve mi opinión, me centraría en los diferentes paradigmas que existen > >> en la programación, siendo completamente secundario el lenguaje. De hecho, > >> cuando me enseñaron a programar, lo primero que me enseñaron fue > >> pseudocódigo, así que lo que en los que deberían centrarse los aprendices > >> es > >> en aprender a razonar, y a leer mucho código ajeno. Ver cómo solucionan > >> otros los problemas, y qué es lo que ha llevado a alguien a tomar una > >> determinada forma de solucionarlo.... > > > > > > En mi opinión (y os habla alguien quien ni siquiera puede considerarme > > aprendiz de pyhton, todavía, aunque sí interesado), lo que comenta Kortatu > > es lo más importante de cara a la enseñanza. > > > > Quisiera aprovechar para pedir algunos enlaces a documentación enfocada a la > > enseñanza de pseudocódigo, si alguien es tan amable :) > > > > El pseudocódigo es para pros, te recomiendo empezar con diagramas de flujo: > http://es.wikipedia.org/wiki/Diagrama_de_flujo > > Luego es facil cambiar los rombos por if's, los bucles por for o > while, ... Y viendo una posible biyección entre una representación > gráfica y una textual podrás elegir la más conveniente a tu forma de > pensar. > http://es.wikipedia.org/wiki/Pseudocódigo > > A la hora de meterte con programación orientada a objetos, te > recomiendo mirar antes los patrones GRASP. Sobre todo la máxima de > alta cohesión y bajo acoplamiento: > http://es.wikipedia.org/wiki/Grasp > > Luego puedes diseñar tus sistemas ayudándote primero de diagramas de > bloques (los bloques se convertirán en módulos o paquetes), diagramas > de clases de cada uno de los bloques después y diagramas de flujo o > pseudocódigo finálmente. Esto te permite tener una jerarquización con > la que ver los detalles tanto generales como específicos de un > proyecto, por ambicioso y complejo que sea. > > Del tema concreto del pseudocódigo no se que decirte. Cualquier paper > sobre un algoritmo concreto que te encuentres suele adjuntar bloques > de pseudocódigo apuntando a como se implementaria. Aunque otros se > limitan a poner una descripción textual y las formulas del cálculo del > orden de ejecución. > http://en.wikipedia.org/wiki/Quicksort#Algorithm > > Un saludo: > > Javi > _______________________________________________ > Python-es mailing list > Python-es@python.org > http://mail.python.org/mailman/listinfo/python-es > FAQ: http://python-es-faq.wikidot.com/ > > _______________________________________________ > Python-es mailing list > Python-es@python.org > http://mail.python.org/mailman/listinfo/python-es > FAQ: http://python-es-faq.wikidot.com/
_______________________________________________ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
