Reservá tú lugar: ubuntupartyczu@gmail.com
jueves, 30 de septiembre de 2010
martes, 14 de septiembre de 2010
APRENDIZAJE BASADO EN PROYECTOS
El Aprendizaje Basado en Proyectos (ABP) es muy exigente para usarlo regularmente en el aula escolar. Muchas de las objeciones sobre el NCLB [1], la presión por realizar mejores evaluaciones, la enseñanza orientada por los datos y mantener enfocados a los estudiantes para que demuestren buen desempeño y obtengan buenos puntajes en los exámenes más demandantes de competencias escolares son válidas, pero el ABP no es el remedio que cura ese mal. Esta es una estrategia de enseñanza difícil de manejar que se ha vendido como cura mágica para todos los estudiantes etiquetados como talentosos, doblemente excepcionales o aquellos necesitados de aprendizajes más significativos. Esta es una herramienta que se está usando con los estudiantes para que generen sus propias respuestas a preguntas y para que piensen más críticamente sobre un tema; también se pretende que simultáneamente y mientras dura el proceso, hagan reflexiones con sus compañeros. En la realidad del aula, donde deben manejarse muchas dificultades y donde los estudiantes luchan por adquirir habilidades básicas, el ABP es una pérdida de tiempo.
El diseño del ABP se originó en las facultades de medicina. Cuando un paciente visita al médico, éste debe hacerle preguntas que le den respuesta al problema que lo ha llevado allí. Como pacientes decimos: "Dr. Gómez, me duele la rodilla". A lo que el doctor Gómez me responderá con una serie de preguntas como "¿Cuándo le empezó el dolor?" "¿Había sentido antes este dolor?, En escala de 1 a10, en la que 10 es el máximo dolor, qué número le daría al dolor que siente? Después de esta evaluación inicial, el doctor prescribe terapia fisca o medicamentos o quizás nos remita a un especialista. En el aula este modelo no funciona así de bien. En muchos casos el problema que se plantea, intencionalmente se describe en forma muy vaga y los estudiantes no entienden cuál es la situación.
En mi clase de historia, la mayoría de los estudiantes no han estado expuestos a las complejidades de la guerra u a otros conceptos difíciles de comprender. Como facilitador, mi trabajo consiste en guiarlos para que formulen buenas preguntas y para que investiguen respuestas a esas preguntas; pero en primer lugar, ¿qué sucede si los estudiantes no están interesados en el tema? La mayoría de los estudiantes de secundaria no demuestran interés por hechos que ocurrieron hace más de 100 años y puede resultar difícil motivarlos por asuntos que no tienen ningún efecto directo en sus vidas.
El ABP tiene ventajas para aprendices avanzados y estudiantes mayores que están cautivados por un tema que les fascina. Nos esforzamos para que todos nuestros estudiantes se interesen en los temas que les presentamos y para que se involucren activamente en su aprendizaje. Nuestros Ministerios de Educación establecen qué deben saber los estudiantes y el NCLB [1] determina si estamos alcanzando esos objetivos. El ABP requiere más tiempo, energía y recursos y sus resultados son marginales o pequeños. Los estudiantes que luchan con el desarrollo de habilidades básicas, tienen mayores dificultades con el ABP porque las bases que tienen no son lo suficientemente sólidas para apoyarlo.
ESOL [2] y los estudiantes que requieren educación especial luchan aún más, y a pesar de nuestros mejores esfuerzos por ubicarlos en grupos de estudiantes "buenos" que les ayuden, terminan frustrados. Los estudiantes frustrados no son exitosos y tampoco culminan sus estudios con mayor conocimiento. En cambio, están menos motivados y muchas veces abatidos. No vale la pena lanzar al agua a esos estudiantes que realmente necesitan nuestra ayuda, sin un salvavidas.
Debemos concentrar nuestra atención en prácticas, ideas fundamentales y estrategias que den resultados; no en aquellas que representan las últimas tendencias educativas o que solo funcionan con estudiantes excepcionales.
Fuente:http://www.eduteka.org
Kevin Scott
Kevin Scott ha integrado las TIC en los ambientes escolares, durante los últimos siete años, para trabajar con estudiantes que tienen una amplia gama de habilidades. Presta sus servicios a equipos escolares de liderazgo y a grupos de desarrollo de currículos en el área de avances tecnológicos. Actualmente realiza una maestría en Tecnología para el aprendizaje en La Universidad Politécnica de Virginia.
martes, 20 de julio de 2010
Alto ejecutivo de IBM obliga a sus empleados utilizar Mozilla Firefox
Algunos dirian por fin se pone orden en la empresa IBM, esta a decisido que lo más de 400,000 empleados de IBM de todo el mundo han recibido la advertencia del vicepresidente Bob Sutor para que utilicen en su trabajo el navegador Mozilla Firefox, en todas sus computadoras como navegador por defecto.
El ejecutivo de IBM recomienda este navegador de Software Libre basicamente por ser de código abierto, estable y sobre todo seguro, según escribe en su página personal. Todos las computadoras de IBM llevarán instalado Firefox y se pondrá en marcha preferentemente, a no ser que el empleado lo cambie por otro. Sutor anima a los clientes de la empresa a que hagan lo mismo por las razones expuestas, al parecer no quiere saber nada con Microsoft Internet Explorer y el navegador Google crhome, desarrollado por la Empresa Google.
"Contamos con miles de empleados que emplean Linux, Mac y computadoras portátiles y de escritorio de Windows, pero vamos a seguir añadiendo miles de usuarios a Firefox", escribe el alto ejecutivo, además vicepresidente de código abierto y Linux en IBM.
La ofensiva de Sutor a favor de Firefox coincide con las últimas estadísticas del uso de navegadores, en las que Firefox, lejos de aumentar su mercado, ha perdido fuelle, bien a favor de Chrome (Google) o, incluso de Safari (Apple). Por primera vez en casi un año, el navegador líder, el Explorer de Microsoft, ha ganado terreno a la competencia y recupera una cuota del 52% de mercado, cuando Firefox ronda el 28%, seguido de Chrome 8,9% y Safari 8,8% en Estados Unidos.
Sin embargo Sutor recuerda que gracias a Firefox, el mundo de los navegadores se renovó y evolucionó, ya que con el dominio abrumador del Explorer apenas se actualizaba. "Creo que fue Firefox y su crecimiento el que ha dado nuevas fuerzas al navegador, así como a la misma web. Firefox obligó a los competidores a responder ". Efectivamente el Explorer después de muchos años sin actualizarse, lo hizo tras la salida exitosa de Firefox, perteneciente a la fundación Mozilla.
!!Y ustedes ya han instaldo Fifrefox en su computadora !!
Fuente: http://somoslibres.org
miércoles, 14 de julio de 2010
¿Microsoft perdiendo el favor de los desarrolladores?
Con motivo de la debacle del teléfono inteligente Kin de Microsoft, que se retiró del mercado sólo 2 meses después de su lanzamiento y con menos de 10.000 unidades vendidas, en el sitio del prestigioso diario The New York Times se publica un artículo donde se pregunta si la empresa de Bill Gates está perdiendo el favor de las generaciones más jóvenes y tecnológicamente más obsesionadas, y, peor aún, también la preferencia de los nuevos desarrolladores que se lanzan a hacer su propia start-up, que prefieren el Open Source.
Particularmente la consecuencia de esto último podría ser desastrosa para Microsoft en el largo plazo, porque perderían su habilidad para dirigir al mercado tecnológico en la dirección que le plazca, como lo hacía cuando Windows como plataforma de desarrollo era omnipresente.
Tim O'Reilly, sí, el mismo de esos libros, lo deja claro con un ejemplo:
"Para los desarrolladores, lo móvil es lo que está de moda ahora, y (en eso) hay dos plataformas que importan: Apple y Android".
Fuente: vivalinux.com.ar
jueves, 10 de junio de 2010
Los Riesgos de las Universidades-Java
Spolsky alerta sobre la creciente tendencia de muchas universidades a sobre-simplificar la currícula de las carreras de Ciencias de la Computación (con Java como "lenguaje insignia"), con el único objetivo de producir mayor cantidad de egresados y en menos tiempo. La consecuencia es directa: cada vez más abundan programadores que poco entienden de conceptos de programación (corrección, recursión, complejidad, paralelismo, entre tantos otros) y para los cuales los mecanismos "internos" de los sistemas informáticos (gestión de memoria, interacción con el sistema operativo, comunicación entre procesos, etc.) son completamente esotéricos.
El principal impulsor de este embrutecimiento es cierto sector de la llamada "Industria del Software" que requiere de mano de obra barata y de pobre formación, y empuja a las instituciones educativas a proveerles "recursos" tan rápido y en tanta cantidad como sea posible (ni qué decir de las instituciones educativas que ceden a esta presión).
Nadie está en contra de hacer la tarea del programador más simple, ni mucho menos de la evolución de los lenguajes y las metodologías de desarrollo de software. Lo que se reprocha aquí es la negación de la realidad como forma de evasión. Esto es: la necesidad de dotar a los programadores de ciertos conceptos, aún cuando esto provoque la deserción de quienes no puedan llegar a dominarlos (y mal que le pese al referido sector de la "Industria").
¿Qué pasó con el trabajo duro?Un seguro indicio de mi decadencia hacia la senilidad son mis continuas quejas y lamentos sobre "los chicos de hoy", y cómo ya no quieren o no pueden hacer cosas difíciles.
Cuando yo era un muchacho, aprendí a programar con tarjetas perforadas. En esos tiempos si cometías un error, no tenías ninguna de esas modernas funciones como la tecla "backspace" para corregirlo. Tenias que tirar la tarjeta y empezar todo de nuevo.
Cuando empecé a entrevistar programadores en 1991, les dejaba usar generalmente cualquier lenguaje que quisieran para resolver los problemas de programación que les planteaba. El 99% de las veces, ellos elegían C.
Ahora ellos tienden a elegir Java.
No me malinterpreten: no hay nada malo con Java como lenguaje de implementación.
Un momento, quiero rectificar eso último. No digo, en este artículo en particular, que haya algo de malo con Java como lenguaje de implementación. Hay un montón de cosas mal con Java, pero tendrán que esperar hasta otro artículo.
En cambio, lo que quiero decir es que Java no es, generalmente, un lenguaje de programación lo suficientemente difícil para que pueda ser usado para distinguir entre excelentes programadores y programadores mediocres. Puede ser un buen lenguaje para trabajar, pero ese no es el tema de hoy. Puedo ir incluso mas allá y decir que el hecho de que Java no sea lo suficientemente difícil es una característica, no un bug, pero que tiene ese problema.
Si puedo ser atrevido, diría que en mi humilde experiencia han sido dos las cosas tradicionalmente enseñadas en las universidades como parte de la carrera de Ciencias de la Computación (CS) las que mucha gente nunca llega realmente a comprender: punteros y recursión.
En aquellos tiempos lo normal era empezar la universidad con un curso de estructuras de datos, con listas enlazadas, tablas hash y, por qué no, con un uso intensivo de punteros. Esos cursos eran frecuentemente usados como filtros: eran tan difíciles que cualquiera que no pudiera soportar el desafío mental de un grado en CS se daría por vencido, lo que era bueno, porque si piensas que los punteros son difíciles, espera hasta intentar probar cosas en teoría de punto fijo.
Todos esos chicos que lo habían hecho muy bien en la secundaria escribiendo juegos de "pong" en BASIC para su Apple II, iban a la universidad, tomaban el curso CompSci 101, sobre estructuras de datos, y cuando llegaban al asunto de los punteros, sus cerebros estallaban completamente; y lo próximo de lo que tenías noticias es que estaban especializándose en Ciencias Políticas, porque la escuela de leyes parecía ser una mejor idea. He visto todo tipo de de índices de deserción en CS y usualmente están entre el 40% y el 70%. Las universidades tienden a ver esto como un derroche; yo creo que es sólo la poda necesaria de gente que no va a ser feliz o exitosa en una carrera de programación.
El otro curso difícil para muchos jóvenes estudiantes de CS era el curso donde aprendías programación funcional, incluyendo programación recursiva. MIT puso una barrera muy alta en esos cursos, creando un curso obligatorio (6.001) y un libro de texto (Estructura e Interpretación de Programas de Computadora de Abelson y Sussman, el cual era usado en docenas o quizás cientos de carreras de CS prestigiosas como el estándar de facto para la introducción a las Ciencias de la Computación. (Puedes, y deberías echarle una ojeada a la antigua versión de las clases en línea).
La dificultad de esos cursos es asombrosa. En la primera clase has aprendido casi todo Scheme, y ya has sido introducido a la función de punto fijo que toma otra función como parámetro. Cuando me esforzaba en pasar un curso similar, CSE121 en Penn, observaba cómo muchos sino la mayoría de los estudiantes simplemente no lo lograba. La materia era muy difícil. Inclusive escribí un largo email de lloriqueando a mi profesor diciendo que "simplemente no era justo". Alguien en Penn debe haberme escuchado (o a alguno de los otros llorones), porque ese curso se dicta ahora con Java.
Desearía que no hubiesen escuchado.
Aquí radica el quid del debate. Años de lloriqueo de estudiantes perezosos como yo, combinados con quejas de la industria acerca de cuan pocos graduados en CS salen de las universidades americanas, han pagado su precio, y en la ultima década un gran numero de otrora perfectamente buenas universidades se han vuelto 100% Java. Esta de moda, a los reclutadores que usan "grep" parece gustarles, y, lo mejor de todo, no hay nada lo suficientemente difícil en Java como para filtrar aquellos programadores sin la parte del cerebro que entiende punteros y recursión. Así es que la deserción es menor, y los departamentos de ciencias de la computación tienen mas alumnos y mayores presupuestos y todo está bien.
Los afortunados chicos de esas Universidades-Java nunca van a toparse con raros fallos de segmentación tratando de implementar tablas hash basadas en punteros. Nunca se van a volver locos tratando de empaquetar cosas en bits. Nunca tendrán que ocupar sus cabezas en cómo en un lenguaje puramente funcional, el valor de una variable nunca cambia, y aun así, ¡cambia todo el tiempo! ¡Una paradoja!
Ellos no necesitan esa parte del cerebro para obtener un 4 en la materia.
¿Soy sólo uno de esos viejos cascarrabias anticuados, vanagloriándose acerca de cuán duro era sobrevivir a todas esas dificultades?
Rayos, en 1900, el Latín y el Griego eran asignaturas requeridas en la universidad, no porque sirvieran de algún propósito, sino porque de alguna manera eran considerados un requisito obvio de la gente educada. De cierta manera mi argumento no es diferente del argumento expuesto por la gente pro-Latín: "[El Latín] entrena tu mente. Entrena tu memoria. Desembrollar una sentencia en Latín es un excelente ejercicio del pensamiento, un verdadero acertijo intelectual y una buena introducción al pensamiento lógico", escribe Scout Barrer. Pero ya no puedo encontrar una sola universidad que requiera Latín. ¿Son los punteros y la recursión el Latín y el Griego de las ciencias de la computación?
Ahora, admito que programar con punteros no es necesario en el 90% del código escrito en la actualidad, y de hecho es totalmente peligroso en el código de producción. OK. Está bien. Y que la programación funcional no es muy empleada en la práctica. De acuerdo.
Pero todavía sigue siendo importante para algunos de las tareas más excitantes en programación. Sin punteros, por ejemplo, nunca serías capaz de trabajar en el Kernel de Linux. No puedes entender una sola línea del código de Linux, o de hecho, de cualquier sistema operativo, sin realmente entender punteros.
Sin entender programación funcional, no podrás inventar MapReduce, el algoritmo que hace Google tan masivamente escalable. Los términos Map y Reduce vienen de Lisp y la programación funcional. MapReduce es, en retrospectiva, obvio para cualquiera que recuerde de su clase equivalente a 6.001 que los programas puramente funcionales no tienen efectos colaterales y por ende son trivialmente paralelizables. El simple hecho que Google inventara MapReduce, y no Microsoft, dice algo del por qué Microsoft está aun jugando a lograr que funcionen algunas características básicas de búsqueda, mientras Google se ha movido ya al siguiente problema: construir Skynet^H^H^H^H^H^H, la mayor supercomputadora masivamente paralela del mundo. Simplemente no creo que Microsoft entienda completamente cuan retrasados están en ese campo.
Pero mas allá de la importancia a simple vista de los punteros y la recursión, su valor real radica en que construir grandes sistemas requiere del tipo de flexibilidad mental que adquieres aprendiéndolos, y de la actitud mental que necesitas para no huir de los cursos en donde son enseñados. Punteros y recursión requieren cierta habilidad para razonar, para pensar en abstracciones, y más importante, para ver un problema en diversos niveles de abstracción simultáneamente. Por lo tanto, la habilidad para entender punteros y recursión esta directamente correlacionada con la habilidad de ser un gran programador.
No hay nada en grado académico 100% Java que realmente descarte a los estudiantes que carecen de la agilidad mental para tratar con esos conceptos. Como empleador, he visto que las Universidades 100% Java han empezado a producir en serie una buena cantidad de graduados quienes simplemente no son lo suficientemente listos para trabajar como programadores en nada mas sofisticado que "Sólo Otra Aplicación Contable en Java", aunque se las han arreglado para colarse a través de la (ahora simplificada) carrera. Esos estudiantes nunca sobrevivirían al 6.001 del MIT o al CS 323 en Yale y, francamente, esa es una razón por la cual, como empleador, un título en CS del MIT o Yale tiene más peso que uno de Duke, que recientemente se hizo 100%-Java, o de Penn, donde remplazaron Scheme y ML por Java tratando de enseñar la materia que casi nos mata a mis compañeros y a mi, CSE121. No es que no quiera contratar chicos listos de Duke o Penn, lo hago, es sólo que es mucho más difícil para mí darme cuenta de cuáles son. Yo estaba acostumbrado a decir que los chicos listos eran aquellos que podían desmenuzar un algoritmo recursivo en segundos, o implementar funciones de manipulación de listas enlazadas usando punteros tan rápido como podían escribir en la pizarra. Pero con graduado sde Universidades-Java, no puedo saber si padecen esos problemas a causa de haber sido mal educados o si los padecen porque realmente carecen de esa parte del cerebro que van a necesitar para ser buenos programadores en el trabajo. Paul Graham los llama "Blub Programmers".
Ya es bastante malo que las Universidades-Java fallen en filtrar los chicos que nunca van a ser buenos programadores, algo que las universidades podrían justificablemente decir que no es su problema. Después de todo es la industria, o al menos los reclutadores-que-usan-grep, quien está pidiendo a gritos que se enseñe Java.
Pero las Universidades-Java fallan también en entrenar las mente de los chicos para ser hábiles, ágiles y lo suficientemente flexibles para lograr buen diseño de software (y no me refiero al "diseño" OO, donde gastas incontables horas acomodando tu jerarquía de objetos, o preocupándote de "problemas" superfluos como "tiene-un" vs. "es-un"). Necesitas entrenamiento para pensar en las cosas a varios niveles de abstracción simultáneamente, y ese tipo de pensamiento es exactamente lo que necesitas para diseñar excelentes arquitecturas de software.
Puedes estar preguntándote si la enseñanza de programación orientada a objetos (OOP) es un buen sustituto de los punteros y la recursión para el filtrado. La respuesta rápida: no. Sin debatir acerca de los meritos de la OOP, simplemente no es lo suficientemente difícil para filtrar a los programadores mediocres. OOP en las universidades consiste básicamente en memorizar un puñado de términos de vocabulario como "encapsulacion" y "herencia" y tomar exámenes del tipo "multiple-choice" acerca de las diferencias entre polimorfismo y sobrecarga. No más difícil que memorizar fechas destacadas y nombres en una clase de historia, la OOP tiene desafíos mentales inadecuados para espantar a los estudiantes de primer año. Cuando te enfrentas con un problema de OOP, tu programa aun funciona, sólo que es algo difícil de mantener. Supuestamente. Pero cuando te enfrentas a un problema con punteros, tu programa produce línea Fallo de segmentación y no tienes ni la menor idea de lo que está pasando, hasta que te paras, tomas una fuerte bocanada de aire y tratas de forzar tu mente a trabajar en dos diferentes niveles de abstracción simultáneamente.
Los reclutadores-que-usan-grep, de hecho, son ridiculizados aquí, y por un buen motivo. Nunca he conocido alguien que pueda usar Scheme, Haskell y punteros en C, que no pueda entender Java en dos días, y crear mejor código en Java que gente con cinco años de experiencia en Java. Pero trata de explicar eso al zombie de Recursos Humanos.
¿Pero que hay de la misión del compromiso con las CS de las facultades de CS? ¡Ellas no son escuelas vocacionales! No debería ser su trabajo entrenar gente para trabajar en la industria. Eso queda para los terciarios y los programas de capacitación del gobierno para trabajadores desplazados, dirán. Ellas se suponen que están para dar a los estudiantes las herramientas fundamentales para vivir sus vidas, no para prepararlos para sus primeras semanas de trabajo. ¿No es cierto?
Aun así, las CS son demostraciones (recursión), algoritmos (recursión), lenguajes (cálculo lambda), sistemas operativos (punteros), compiladores (cálculo lambda), y entonces la conclusión es que la Universidad-Java que no enseña C y no enseña Scheme, tampoco está enseñando realmente ciencias de la computación. Tan inútil como el concepto de currificación de funciones puede serle al mundo real, es un obvio prerrequisito para un graduado en CS. No puedo entender por qué los profesores en las comisiones curriculares de las facultades de CS han permitido que sus programas sean embrutecidos a tal punto que no sólo no pueden producir programadores operativos, sino que ya ni siquiera pueden producir graduados en CS que puedan obtener PhDs y puedan competir por sus puestos de trabajo. Oh, esperen. No importa. Quizás entienda.
Si volvemos en el tiempo y analizamos las discusiones que tomaron lugar en el mundo académico durante el "Gran Levantamiento Java", encontraremos que la mayor preocupación fue que Java no era lo suficientemente simple para ser usado como un lenguaje de enseñanza.
Mi Dios, pensé, ¡están tratando de embrutecer la curricula aun mas! ¿Por que mejor no le llevamos la comida a la boca a los estudiantes? Dejemos que los ayudantes de cátedra den los exámenes por ellos también, entonces nadie se cambiara a Estudios Americanos. ¿Cómo se supone que alguien aprenderá algo si la curricula ha sido cuidadosamente diseñada para hacer todo más fácil de lo que ya es? Parece haber una comisión de trabajo (PDF) intentando idear un subconjunto simple de Java que pueda ser enseñado a estudiantes, produciendo documentación simplificada que esconde cuidadosamente toda esa basura EJB/J2EE de sus tiernas mentes, de manera tal que no tengan que preocupar sus cabecitas con otras clases que no necesiten para resolver sus aun más fáciles problemas de CS.
La interpretación mas compasiva de por qué las facultades CS son tan entusiastas en embrutecer sus clases es porque ello les dará más tiempo para enseñar verdaderos conceptos de CS, así no necesitaran dos clases enteras para esclarecer a los alumnos las diferencias entre, digamos, un int y un Integer en Java. Bueno pero si ese fuera el caso, 6.001 tiene la respuesta perfecta: Scheme, un lenguaje de enseñanza tan simple que el lenguaje entero puede enseñarse a estudiantes brillantes en unos 10 minutos; entonces puedes gastar el resto del semestre enseñando puntos fijos.
Esta traducción está basada en la versión disponible en el Wiki de Joel Spolsky, corregida y adaptada por http://blog.smaldone.com.ar.
miércoles, 19 de mayo de 2010
Probando Ubuntu Unity
No podíamos esperar seis meses a probarlo. Así gracias a que Canonical nos ofrece la posibilidad de probar Ubuntu Unity en nuestros equipos con Lucid Lynx instalado no ibamos a perder más tiempo ¿No?
Arrancando desde Usb-Live en un Pc que no lo soporte
Ya puestos a tratar temas de luchar con equipos del Jurásico ya salta la pregunta. Como puedo arrancar un Usb-Live con Linux en un Pc tan antiguo que no soporta su Bios el inicio mediante Usb.
Plop! Plop es la respuesta. Se trata de una herramienta que crea una capa intermedia sobre la Bios permitiendo el arranque desde un Usb-Live de nuestra distro preferida.
Plop! Plop es la respuesta. Se trata de una herramienta que crea una capa intermedia sobre la Bios permitiendo el arranque desde un Usb-Live de nuestra distro preferida.
Suscribirse a:
Entradas (Atom)