El popular juego de vídeo de Microsoft, Minecraft, ayuda a los niños a aprender de todo, desde programación, ciencia y matemáticas hasta arte, idiomas e historia.
por Stephen Shankland
¿Preocupado porque no puedes apartar a tu hija de Minecraft? ¿Te preocupa que tu hijo pasa cada momento obsesionardo con cada movimiento del super-popular videojuego?
Relaja. Resulta que Minecraft crea células del cerebro en lugar de disolverlas.
Minecraft no se trata de espadas sangrientas o quemar rueda. No tiene líneas de la historia complejas o imágenes magníficamente creadas de soldados extraterrestes. En su lugar, está lleno de gente, animales, árboles y edificios que se ven como si estuvieran construidos a partir de Legos pixelados. Y en cierto modo, lo es: El universo Minecraft se compone de bloques que representan materiales como tierra, árboles, piedra, minerales y agua. Los jugadores minan estos materiales y luego usan estos bloques para crear los refugios, herramientas y armas que necesitan para protegerse contra los ataques nocturnos de monstruos llamados "mobs".
Cuando superan los conceptos básicos, los niños pueden dejar correr su imaginación, creando mundos con los medios de transpote, los pollos voladores o la lluvia que brota del suelo.
Durante el proceso, los jóvenes jugadores de Minecraft aprenden cosas como la codificación informática, ingeniería, arquitectura, urbanismo y matemáticas.
"Me encanta el aspecto de programación. Permite cambiar el juego por completo", dice Aiden LaFrance, de 10 años de edad, de Raton, Nuevo México, que ha estado jugando Minecraft desde que tenia 6. El último proyecto de Aiden es un rastrillo - la puerta defensiva que protegía a los castillos medievales - que se eleva de forma automática cuando un personaje camina delante de él. Él detalla su trabajo en YouTube, con una explicación completa de como funcionan los extensores de doble pistón y la torre de la antorcha.
"Me gustaría ser programador," dice Aiden. "Creo que Minecraft me ayudará a serlo."
Hay una enorme impulso hoy en día por abrir la educación informática e iniciar a más personas a la programación, algo que creo que es increíble y me habría gustado que se tuvieran más de una iniciativa cuando estaba en la escuela. Vamos a ver muchas más personas que son capaces de leer y escribir código en un futuro, y eso es emocionante.
Pero hay un concepto que escucho un montón (realmente de gente ajena a la tecnología) que dice que va a necesitar empezar a aprender a programar para hacerse un hueco en el mundo laboral tan competitivo que estamos y vamos a vivir en el futuro. Creo que esto es fundamentalmente falso, ya que uno de los objetivos de la tecnología es hacer las cosas accesibles cuando antes no lo eran. Eso incluye tareas que en principio las realizaban los programadorers, a lo que la respuesta no es un ''necesito aprender a programar'', lo que sería complicarse la existencia. En cambio, es una oportunidad en la que los programadores pueden entrar y simplificar las cosas.
Algunas de las funciones que se han hecho más accesibles hace relativamente poco tiempo (nota: no las he usado todas):
Data Scraping - Herramientas como Kimono Labs e Import.io han hecho que sea fácil convertir páginas web en información util sin necesidad de código (suponiendo que las estructuras de las páginas sean similares).
Uso de interfaces API - Una herramienta que me ha impresionado últimamente es Blockspring, que le permite conectar a las API y extraer datos directamente de estas (en lugar de realizar consultas SQL complejas). Aunque nunca lo he utilizado, he oído de otras herramientas como APISpark son una buena manera para que los no desarrolladores implementen sus propias APIs que otros puedan utilizar. Y me han comentado de este sitio como una forma de convertir archivos JSON a CSV para para usuarios con nivel medio en excel: http://konklone.io/json/
Automatización - Compañias como IFTTT y Zapier han hecho fácil la creación de "recetas" para automatizar cosas. Si puedes describir lo que tratas de hacer, lo puedes hacer con estas herramientas.
Desarrollar Apps/Página Web - Squarespace, WordPress y Weebly son algunas herramientas que permiten a lagente construir su sitio web de forma rápida (WordPress ahora esta detrasd de una cuarta parte de la web!). Appsbar, Infinite Monkeys, y AppMachine son sitios web que permiten crear una aplicación móvil facilmente.
Visualización de Datos - Silk y Tableau son unas muy buenas herramientas para presentar datos de forma rápida y agil, mientras que Prezi y Venngage pueden ayudar a hacer presentaciones e infografías para hacer que los puntos principales resalten.
Estas funciones cada vez serán más fácil en el tiempo. Recuerdo crear las páginas web con Dreamweaver, la mejor solución allá por el año 2001 si no sabías programar. Incluso entonces, tardé unos días para aprender a usarlo, y luego otras tantas horas para desarrollar sitios web. Hoy, he construido mi blog en poco menos de una hora y media gracias a WordPress y plugins de código abierto.
Las empresas del día de mañana se pueden construir mediante la comprensión de las necesidades de los no desarrolladores, intentando facilitar sus procesos de trabajo. Cada vez que alguien no técnico acude a un programador para pedir ayuda, se tiene una oportunidad. Cada vez que un proceso requiere de un aprendizaje de horas antes de llevarlo a cabo, no se está siendo eficiente. Es importante escuchar los problemas del personal no técnico, porque nunca se sabe si la solución a este problema es el siguiente elemento de cambio en el proceso productivo.
Are there any particular tools you use and like? Feel free to reach out to me on twitter@nikillinit
¿Hay alguna herramienta que te guste en particular? Puedes comentarla libremente tanto en la cuenta de twitter de Nikhil Krishnan (autor original), @nikillinit, como en la mia, @pnacar, (autor de la traducción)
Disclaimer: hablo en términos absolutos para abreviar. Si, casi cada "regla" en programación tiene excepciones.
. . .
JavaScript es duro. Se mueve tan rápido que con frecuencia es poco claro que es lo que "estas haciendo mal" en un momento dado. Hay días que parece que las partes malas superan a las buenas.
Ya no hay lugar para luchar contra lo evidente. JavaScript se está comiendo el mundo. Asi que hagamoslo bien.
Aqui va una parte.
1. JS dentro de un archivo .js
"Hombre, son solo unas lineas..." Si, me refiero a *casi todo. ¿Por qué? Porque ayuda a la legibilidad, refuerza la estructura, y ahorra ancho de banda. El código JavaScript embebido debe ser descargado cada vez que la página es cargada. Por el contrario, el codigo separado en .js se alamcena en chaché. Como verás, esta regla es ayuda a mantener una larga lista de reglas por venir. Es por eso que es la regla #1.
2. JS debería ser estático
He visto muchos hacks creativos para hacer que JavaScript sea dinámico. La gente usa lenguajes de entorno servidor como C#, Ruby o Java para escribir JavaScript dinámico en una cadena de texto. No lo hagas. Pierdes los colores de código, resaltado de sintaxis y soporte de autocompletado. Y recuerda, el JavaScript a un archivo .js (regla #1).
En su lugar, usa JSON para introducir comportamiento dinamico. Lo llamo Configuración de Patrones de Objeto de JavaScript (JavaScript Configuration Object Pattern). He aquí como: inyectar JSON en la cabecera de tu aplicación y utiliza estos datos para desarrollar la lógica como necesites. Puedes pensar "Oye, esto contradice la regla 1". Veo a JSON como datos, no código, por lo que hago una excepción aquí para soportar archivos estaticos y separados en JavaScript
StackOverflow uses this pattern. As does Google. So you’re in good company. Just view their source: StackOverflow usa este patrón. También Google. Asi que estás en buena compañia. Echa un vistazo a su código:
Tenga en cuenta la parte de JSON. Esto es simplemente una clase del lado del servidor que se ha serializado a JSON y se ha inyectado en la página.
Como puedes ver, StackOverflow está inyectando configuraciones personales como isNoticesTabEnabled. Este simple snippet de JSON provee de los datos necesarios para proveer comportamientos a medida usandose archivos estáticos de código JavaScript. Para que esto funcione, serializa una clase del lado del servidor a JSON y coloca el resultado en <head>. Luego podrás referenciar estos datos estructurados cuando se necesiten en tu código JavaScript, sabiendo que está disponible al estar inyectado en <head>
3. JS debería ser Minified
Minimizar el código reduce el tamaño del archivo, lo que incrementa la carga de la página. Recuerda, el rendimiento es una rasgo. Y, por supuesto, para minimizar, necesitas colocar JavaScript en un archivo aparte (de nuevo, la regla #1). Hubo un tiempo en el que minimizar el código era algo molesto. Hoy, es un proceso automático y simple. Existen docenas de maneras de hacerlo, pero Gulp con su gulp-uglify es una manera facil y automatizada forma de hacerlo.
4. JS va al final
Si colocas la etiqueta <script> dentro de <head>, esto provoca que se bloquee el renderizado. Los scripts deben de ser cargados después de que el cuerpo sea mostrado. Asi que coloca las etiquetas <script> en el fondo, justo antes de <\body>, permitiendo que se carguen los elementos visibles sin tener que esperar a que se descarguen los scripts. Esto ayuda a mejorara la percepción de rendimiento al dar a tus usuarios una pronta vista. Si vas a escribir JavaScript que deba estar en <head>, considera usar algo como $(document).ready de jQuery, por lo que no se ejecutará hasta que el arbol DOM no esté listo.
5. JS debería ser depurado (Linted) en tiempo real
Depurar refuerza las guias de estilo, encuentra erratas, y ayuda a prevenir errores. Hay una variedad de depuradores, pero la sugerencia es ESLint. Puedes ejecutarlo vía Gulp con gulp-eslint. Gulp revisa todos tus archivos JS y se ejecuta cada vez que pulsar guardar. Oh, otra vez, necesitas tus JS en archivos .js separados para depurar. ¿Empiezas a ver por qué puse "JS dentro de un archivo .js" como regla #1?
6. JS debería tener test automáticos
Entendemos que testar era importante en el servidor hace años. Pero esto ha sido ignorado en JavaScript hasta hace bien poco. Una aplicación típica de JavaScript de hoy en día es más extensa de lo que podrías probar a mano regularmente. Usar asistentes de JavaScript es mucho más que lógico, es critico tener tests automatizados.
Puedes realizar la integración automatizada de testing automáticos con herramientas tales como Selenium. No obstante, estos tests suelen ser bastante delicados, así que sugiero centrarnos en testing unitario. Existe una variedad de opciones para realizar testing unitario automatizado. Sugiero Jasmine si eres nuevo en JavaScript testing y Mocha con Chai si quieres lo último en opciones de configuración.
7. JS deberia estar encapsulado
Hace años que hemos aprendido los riesgos de las variables globales. Afortunadamente, hay muchas maneras de encapsular en JavaScript hoy en día:
Este último apartado, los módulos ES6 son el futuro. La buena noticia es, a pesar de no estar soportado todavía en los navegadores, puedes usar los módulos ES6transcompilas a traves de Babel (y los verás más abajo, o deberías).
Si no quieres transcompilar, CommonJS es tu mejor opción. Desde que Node usa el patrón CommonJS, puesdes usar npm para lanzar hasta 1000 paquetes. CommonJS no se ejecuta sin una librería ( shim), así que tendrás que usar estos paquetes para navegadores como Browserify, Webpack, o JSPM.
8. Las dependencias JS deben de ser explícitas
Esta regla está íntimamente relacionada con la de arriba. Una vez que has empezado a encapsular tu código JavaScript, necesitas una forma fácil de referenciar a otros módulos. Esto es lo bonito de los sistemas de módulos modernos como CommonJS y ES6. Simplemente especificas tus dependencias en las `rimeras lineas del archivo, casi como una importación o declaraciones en Java o C#. JavaScript se nos ha hecho mayor.
La última versión de JavaScript, EcmaScript 2015 (más conocida como ES6) fue oficialmente publicada en junio. Los navegadores aún carecen de soporte de la mayoría de características nuevas, pero no importa. Puedes disfrutar de la larga lista de nuevas características hoy usando Babel. Babel transcompila ES6 a ES5. Y asumiendo que podrás vivir con algunas peculiaridades de rendimiento, podrás difrutar de las nuevas caracterisitcas hoy. Se espera que se publiquen una nueva versión de JavaScript una vez al año a partir de ahora, asi que probablemente nos toque transcompilar más a menudo. Transcompilar es el futuro a día de hoy.
¿O quizás te encanta el confort del tipado fuerte? Entonces considera TypeScript como compilador JavaScript.
Aquí la última linea:
Ya no tienes que escribir ES5. Considera usar una abstracción que te dé una potencia extra
10. JS debería tener uan versión automátizada
Ya hemos hablado de depuración, minimizado, transcompilación y testing. ¿pero cómo hacemos todo esto de forma automática? Simple: con un software que lea los archivos. De nuevo, Gulp es una herramienta popular que reune todas las anteriores a través de su función de revisión, pero Grunt junto a Webpack son otra opción a considerar. O, si eres un genio en Bash, simplemente usa npm como editor de JS. La cuestión: no esperes que la gente recuerde como ejecutar esto manualmente. ¡Automatiza y disfruta del resultado!
11. Usa un Framework o librerías
Empieza a usar código ya desarrollado. ¿Necesitas luz? Prueba Backbone o Knockout. O quizás jQuery en plano sea suficiente. ¿O quizas algo mas completo funcionalmente o dogmático? Prueba Angular, Ember o React junto a Flux.
El punto de esto es :
No intentes empezar de cero. Somos enanos a hombros de gigantes
Independientemente del framework que elijas, asegúrate de separar sus funcionalidades. Lo que nos lleva al siguiente punto...
12. JS debería separar funcionalidades
Es fácil caer en el hábito de colocar todo el código JavaScript en un solo archivo, o seguir a ciegas las indicaciones del framework. No olvides lo que has aprendido del lado del servidor cuando te muevas al lado cliente.
Por separar funciones, no me refiero exclusivamente a separar modelos, vistas y controladores en estilo de framework MV* como Angular o Knockout. Me refiero a:
Piensa como un desarrollador de lado del servidor cuando escriba JavaScript. Separa la presentación de la lógica de negocio y del acceso a datos.
Esto significa que las llamadas de AJAX deben estar en un solo sitio. Crear una "capa de acceso a datos" centralizada del lado del cliente. Esto también significa que la lógica que no tiene que ser parte del marco de la capa de presentación que debes ubicar en "POJOs" (Plain ‘ol JavaScript objects) separados. Los módulos de lógica de negocios deben contener JavaScript plano -en otras palabras, no debe de contener código específico del Framework. Esto hace que la lógica sea fácil de reutilizar, fácil de probar, y no esté afectada cuando se decida a pasar de Angular a otro Framework mejorado.
Bueno, eso fue abrumador.
Si, ciertamente.
Hemos entrado en una era en las que el front-end es lo suficientemente complicado que necesitamos especialistas en front-end.
Hoy os propongo un movimiento que me ha llamdo la atención: The Hour of Code. Es un proyecto que pretende llevar la programación a cualquier persona, auqnque te parezca lejano y no tenga ninguna experiencia. Según su sitio web:
La Hora del Código es un movimiento global, que llega a decenas de millones de estudiantes en más de 180+ países. Cualquier persona, en cualquier lugar puede organizar un evento Hora de Código. Tutoriales de una hora están disponibles en más de 30 idiomas. No se necesita experiencia. Para edades entre 4 y 104 años.
Pregunta: ¿Puedo usar JavaScript para detectar el sistema operativo en el lado cliente? Respuesta: Pues si, mi querido usuario de
. Para detectar el sistema operativo en la máquina cliente, puedes consultar el valor de la variables navigator.appVersion o navigator.userAgent.
A continuación se muestra un ejemplo sencillo de un script que establece el nombre del sistema operativo variable para reflejar el sistema operativo cliente real.
<scripttype="text/javascript"> <!--
// En este script se estable la variable OSName el nombre del sistema operativo tal como sigue:
// "Windows" para todas las versiones de Windows
// "MacOS" para todas las versiones de Macintosh OS
// "Linux" para todas las versiones de Linux
// "UNIX" para todas las versiones de UNIX
// "Unknown OS" indica fallo al detectar el sistema var OSName="Unknown OS"; if (navigator.appVersion.indexOf("Win")!=-1) OSName="Windows"; if (navigator.appVersion.indexOf("Mac")!=-1 OSName="MacOS"; if (navigator.appVersion.indexOf("X11")!=-1) OSName="UNIX"; if (navigator.appVersion.indexOf("Linux")!=-1) OSName="Linux";
