sábado, diciembre 31, 2016

La Guerra Fría de la Tecnología: Aún Aquí y Aún Siendo Utilizada

La Guerra Fría de la Tecnología: Aún Aquí y Aún Siendo Utilizada
BY NERMIN HAJDARBEGOVIC - TECHNICAL EDITOR @ TOPTAL #ColdWar #ColdWarTech #CyberCrime #CyberWarfare #Technology This article was originally written in English

Soy un chico de la Guerra Fría. Crecí viendo las noticias de las implementaciones Europeas de Pershing II y SS-20, también de la guerra soviética en Afganistán, con un poco de acción de Terminator y Top Gun VHS. Yugoslavia estaba intentando jugar para ambos lados, y durante un tiempo funcionó a la perfección. Sin embargo, todo se estrelló un par de años después con la caída del Muro de Berlín, haciendo que nuestra destreza se alineara sin sentido.
Admito que esta es una extraña introducción para un blog de tecnología, pero tengan paciencia conmigo, empezará a tener sentido. A diferencia de la mayoría de los europeos, hemos tenido muy buenas relaciones con ambos bloques. Hemos vendido tanques a Kuwait y artillería de cohetes a Saddam, compramos combustible barato y MiGs de los Soviéticos y, a cambio, hemos exportado algunas cosas que no podíamos obtener directamente desde el Oeste. Sé de gente que se hospedó en hoteles de Berlín Oriental porque eran más baratos, luego cruzaban la frontera a Berlín Occidental para trabajar, jugar y comprar, sólo para cruzar de nuevo a través lugares imprácticos como el Checkpoint Charlie, todo en cuestión de horas.
En uno de estos viajes, mi papá me consiguió un Commodore C64, el cual fue lanzado como maquinaria de la Guerra Fría. La mayoría de los videojuegos de la década de 1980 y, de hecho, un montón de música y películas, fueron inspirados por incontables guerras y la amenaza de un apocalipsis nuclear. Con la caída del muro, mucha gente supuso que sería el final del caos, en especial en el gasto en defensa y que por ende el mundo sería un lugar más seguro. No fue exactamente de esta manera, ¿o si?
Sin embargo, el efecto a largo plazo de la Guerra Fría en ciencia y tecnología es más profundo que el Nena 99 Luftbalons, o que el Oliver Stone Vietnam flick.

Minuteman: Un Caso de Estudio Técnico de la Guerra Fría

Si estás leyendo esto, entonces estarás utilizando una tecnología desarrollada por guerreros de la guerra fría: El Internet. Eso no es todo. Un montón de la infraestructura y de la tecnología que nosotros damos por sentado fue desarrollada, o al menos concebida, durante estos decenios tumultuosos.
¿La constelación de satélites GPS orbita alrededor de la tierra? No fue puesto allí para geoetiquetar selfies u obtener un Uber ride; fue diseñado para ayudar a que el Comando Aéreo Estratégico de Estados Unidos entregara cientos de megatones v por valor de sol instantáneo sobre objetivos Soviéticos con una precisión milimétrica. ¿Circuitos integrados, transistores, y computación de estado sólido? Afirmativo, todas desarrollados por las fuerzas armadas y pagados por los contribuyentes estadounidenses.
Aquí hay un ejemplo de lo anterior: el elegante e inigualablemente mortal LGM-30 Minuteman de misiles balísticos intercontinentales (ICBM). No fue el primer ICBM ahí fuera, pero cuando apareció en el mercado, fue revolucionario. Fue un misil de combustible sólido, lo que significa que pudo responder a una amenaza y el lanzarse en un minuto sin tener que ser alimentado; por esto se le llamó así. Pero el combustible sólido es sólo parte de la historia: el combustible sólido era mucho más interesante desde un punto de vista geek. Antes de Minuteman, ICBMs dependió en computadoras análogas, giroscopios y sensores mecánicos primitivos. Desde que estos fueron transferidos a un objetivo específico, el paquete de destino no se puede cambiar fácilmente. El Minuteman fue la primera implementación masiva de una computadora digital de propósito general; un piloto automático integrado y sistema guiado de misiles en un solo paquete, con un almacenamiento fiable y que podría tener el estrés de un silo de lanzamiento. El equipo también fue capaz de almacenar varios destinos, y era reprogramable.
Los transistores no eran nada nuevo en ese punto; fueron desarrolladas años antes por los laboratorios Bell. Sí, estos primitivos transistores eran casi exclusivamente reservados para el complejo militar-industrial. El tío Sam era el único cliente de prácticamente todas las primeras computadoras y chips, quemando montones de dinero. Estos primeros transistores ofrecieron un salto cuántico a través de tubos de vacío, pero no eran perfectos. Para los estándares de hoy, eran una basura. La fiabilidad simplemente no estaba allí, y si necesitas lanzar unos cuantos cientos de ojivas termonucleares a medio camino a través del planeta, necesitas una especie de sistema guiado el cual que no podría fallar, tan pronto como la vela se encendía.
Entonces, ¿qué puedes hacer cuando te encuentras con un problema técnico, el cual no se puede resolver con dinero? Simple: tirar más dinero en ello, y eso es exactamente lo que hizo la Fuerza Aérea de los Estados Unidos. Quemaron a millones para hacer la maldita cosa lo suficientemente fiable como para ser utilizado en entornos hostiles y sobrevivir el estrés de un alto-G que asciende hacia el espacio. Esto se conoce como el programa Minuteman de Alta Fiabilidad (Hi-Rel).
El primer ordenador digital móvil de verdad fue algo más letal que el ordenador portátil y el iPhone.
El primer ordenador digital móvil de verdad fue algo más letal que el ordenador portátil y el iPhone.
Funcionó, pero la USAF tuvo un poco más de lo que se esperó. En tratar de mejorar un sistema de armas sola, la USAF terminó dando un gran impulso a la industria de la tecnología en general. Finalmente, el Minuteman se ha actualizado para incluir un nuevo sistema de referencia basado en microchip, con una forma primitiva de almacenamiento de estado sólido. Esta reliquia de la Guerra Fría ha estado en servicio desde la administración Kennedy, y la encarnación actual ha sido de alrededor de 45 años, recibiendo múltiples actualizaciones de hardware y software en los últimos años.
Por lo tanto, al esbozar el desarrollo y la evolución de un sistema de una sola entrega de arma estratégica single, me he referido a una serie de tecnologías vitales que damos por sentado: transistores, chips, fiables de almacenamiento de estado sólido, ordenadores programables fabricados en serie y así sucesivamente. El Minuteman fue también la primera computadora mobile digital.
Algunos pueden argumentar que el legado de este tipo de armas es aquel de Destrucción Mutua Asegurada (MAD), garantizado por la tríada nuclear que mantiene a las superpotencias en ir a la guerra total. Probablemente lo hizo, pero al hacerlo, también permitió a los ingenieros de todo el mundo desarrollarán tecnologías y conceptos aplicables en diversas industrias y campos de estudio.
Su verdadero legado radica en cada circuito integrado en el planeta.

Pioneros Capitalistas Tratan de Aprovecharse

¿Qué podría ser más capitalista que monetizar los instrumentos de destrucción masiva? ¡Los contribuyentes pagan para su desarrollo, no los capitalistas de riesgo!
Bromeando aparte, se puede argumentar que el Red Scare de los años cincuenta creó Silicon Valley. La mayor parte del dinero en realidad provenía de los contribuyentes y la mayoría de las empresas ganadoras de contratos lucrativos de defensa no tardaron en hacer una pelota en la tecnología de doble uso desarrollado para los militares. ¿Recuerdas a los Laboratorios Bell? Algunos de sus personas más brillantes pasaron a co-fundar Fairchild Semiconductor y, finalmente, crearon Intel una década más tarde. El equipo de orientación Minuteman actualizado se basa en chips de otro gigante de los semiconductores, Texas Instruments.
No discuto la inteligencia de las personas co-fundadoras de Intel por ejemplo, como Robert Noyce y Gordon Moore. No tengo ninguna duda de que hubieran dejado su huella en la industria de la tecnología, inclusive sin la carrera más grande de los brazos en la historia, pero también es difícil negar que la industria de la tecnología no se habría desarrollado casi al mismo ritmo si no hubiera existido la financiación del gobierno. Sí, los contribuyentes subsidian efectivamente la industria de la tecnología desde hace décadas, pero al largo plazo, esto es probablemente mejor. Westinghouse no necesitaba subsidios para desarrollar lavadoras y refrigeradores, porque la demanda de los consumidores era fuerte, pero en los primeros días de la informática, no había prácticamente ninguna demanda de los consumidores. Es por eso que los gobiernos tuvieron que intervenir.
¿Pero qué consiguió el contribuyente?
El Internet, GPS, transistores y chips fiables:. Guerra Fría tecnología hecha posible por el gasto de defensa fuera de control.
El Internet, GPS, transistores y chips fiables:. Guerra Fría tecnología hecha posible por el gasto de defensa fuera de control.
El espacio y la competencia dio lugar a una serie de tecnologías que a su vez crearon un sinfín de oportunidades de negocio. Inclusive los ordenadores primitivos tuvieron un profundo impacto en la industria. Hicieron las redes de energía y la infraestructura de transporte más eficientes, ayudaron a mejorar la seguridad de las instalaciones industriales, incluyendo los químicos sensibles e instalaciones nucleares, cambiaron la faz de la banca, comunicaciones, entretenimiento y así sucesivamente.
Lo mejor de todo es que de alguna manera logramos no soplarnos a nosotros mismos con las armas estas tecnologías han hecho posible, sin embargo, al mismo tiempo, se volvieron espadas en rejas de arado. Ya en los años cincuenta, los EE.UU. y la Unión Soviética pusieron en marcha iniciativas destinadas a examinar usos civiles de la energía nuclear (incluidos los planes de explosivos nucleares de ingeniería civil, que fueron terribles), pero no significaba nada. No era la fuerza del átomo que cambió el mundo; fue el humilde microchip y tecnologías auxiliares desarrolladas para programas de defensa innumerables, que lo hicieron.
Antes de que dejaron su marca en la ciencia y golpearon a Gary Kasparov en la mesa de ajedrez, superordenadores y sus predecesores analógicos se utilizaron para simular procesos físicos vitales en el desarrollo de armas termonucleares. Una ventaja pura en potencia de cálculo podría producir avances en innumerables campos. Las simulaciones por ordenador permitieron a las armadas Occidentales en desarrollar submarinos más silenciosos con tornillos nuevos; optimizados digitalmente para evitar la cavitación. Procesadores de Señal Digital (DSP) hicieron sonares mucho más sensibles, y un par de décadas más tarde, los DSP avanzados hicieron que la música sonará mejor. El diseño asistido por ordenador no se acabó de utilizar para reducir la sección transversal de radar de los aviones, sino que también hizo que nuestros edificios y automóviles fueran más baratos, más seguros y más eficientes.
Algunos de estos esfuerzos resultaron en un callejón sin salida tecnológica, pero la mayoría no lo hicieron. Uno de mis favoritos fue Blue Peacock, una mina nuclear británica (sí, las minas terrestres, no de bomba), con un peso de 7,2 toneladas. Ya que confió en la tecnología temprana de la década de 1950 y tuvo que ser enterrado en el campo Alemán, los ingenieros se dieron cuenta rápidamente de que el frío podría matar a los componentes electrónicos en el interior, por lo que trataron de encontrar la manera de mantener los circuitos calientes. Su solución era tan descabellada que fue confundida con una broma del Día de los Inocentes cuando el diseño fue desclasificado el primero de Abril del 2004.
Ningún pollo fue afectado en la elaboración de esta entrada del blog, o en el programa de minas nucleares Blue Peacock.
Ningún pollo fue afectado en la elaboración de esta entrada del blog, o en el programa de minas nucleares Blue Peacock.
Un pollo debía de ser sellado dentro de su carcasa, con suficiente comida y agua para mantenerse con vida durante una semana. Su calor corporal mantendría la bomba eléctrica en funcionamiento.
A medida que las industrias civiles empezaron a aplicar estas tecnologías de vanguardia en masa, nuestra calidad de vida y la productividad se disparó de manera exponencial. Nuestros televisores, automóviles, teléfonos, la ropa que usamos, y casi cualquier producto de consumo que compramos: Son todos mejor gracias a la mayor pérdida de dinero en la historia. Por supuesto, todos tenemos pequeñas cantidades de estroncio 90 en los huesos, pero a gran escala, es un pequeño precio a pagar por el mundo de alta tecnología que nos gusta tanto.
Oh, sí, también nos dieron los videojuegos. Montones y montones de juegos de video.
Like what you're reading?
Get the latest updates first.
No spam. Just great engineering and design posts.

Haciendo un Kickstarter Para el Desarrollo de Video Juegos

Los videojuegos fueron iniciados en los equipos digitales más tempranos (y algunos analógicos también). De hecho, Tennis para Dos, posiblemente el primer juego en utilizar una pantalla gráfica, fue desarrollado por un equipo analógico en 1958. Sin embargo, ni siquiera los villanos de Bond tenían computadoras en ese momento, por lo que el aumento de la industria de los videojuegos tuvo que esperar al hardware para madurar.
A mediados de la década de los setenta, los microchips se volvieron lo suficientemente baratos para aplicaciones del mercado de masas. Ahora que teníamos el hardware, ya sólo necesitábamos algunos desarrolladores de software y un caso de uso de chips baratos. Dado que el consumidor medio, no estaba interesado en los ordenadores caros y complicados que fueron diseñados para las grandes empresas, la atención se desplazó a los juegos; soportales, consolas de videojuegos y computadoras de bajo costo como el ZX y C64.
Estas humildes máquinas llevaron computadoras programables a millones de hogares, enganchando una generación de niños en el entretenimiento digital, y creando oportunidades para los desarrolladores de video juegos. Consolas y ordenadores baratos trajeron el arcade de la sala de estar, marcando el comienzo de una nueva era de juegos de vídeo, y la creación de innumerables puestos de trabajo en la industria. Incluso los Soviéticos lo consiguieron con el Tetris, uno de los primeros juegos.
El advenimiento de los ordenadores personales de bajo costo y consolas de juegos creó una generación enganchada en la informática y la codificación.
El advenimiento de los ordenadores personales de bajo costo y consolas de juegos creó una generación enganchada en la informática y la codificación.
No solo era un entertainmento. A diferencia de las consolas, el ZX y el C64 eran equipos adecuados, y los niños geeks rápidamente encontraron nuevos usos para ellos. Ellos comenzaron a hacer demostraciones, y empezaron la codificación. Lo más probable es que tu sabes mucho de estos niños, y si estás leyendo esto, es probable que trabajas con algunos de ellos.
Si estás interesado en el desarrollo de los primeros videojuegos, y lo que la Guerra Fría tuvo que ver con ellos, yo sugiero que consultes FrutaNuclear; un nuevo documental que es una visita obligada para los jugadores nacidos en las década de 1970 y principios de la década de 1980.
Estos chicos y chicas pasaron a desarrollar una nueva generación de juegos de vídeo, creando exitosos negocios en línea, creando nuevas tecnologías y revolucionando el mundo digital, todo en el espacio de una década. Una generación que creció con la constante amenaza de una guerra nuclear, disfrutando de la distópica ciencia ficción, la cual ayudó a hacer del mundo un lugar mejor. Ellos no desarrollaron Skynet, desarrollaron millones de aplicaciones móviles y web en su lugar.
Por lo tanto, no hay Terminators. Al menos no todavía.

2.0 Guerra Fría y el Surgimiento de Nuevas Amenazas

Este no es un blog geopolítico, pero si estás al tanto de las noticias, es probable que sepas que el mundo es un lugar desastroso. No, el final de la Guerra Fría no trajo una era de paz y estabilidad, y ya se habla de una “Segunda Guerra Fría”, o peor, una guerra “Caliente”. Mientras que la mayoría de estas preocupaciones no son más que exageraciones y sensacionalismo, una serie de graves amenazas permanecen. La amenaza de la aniquilación nuclear casi ha desaparecido, pero la tecnología que nos gusta tanto ha creado una serie de amenazas y posibles problemas, que van desde la privacidad y la seguridad, hasta las preocupaciones éticas.
Afortunadamente, no es probable que veamos una carrera de armamentos para competir con el que hemos presenciado en el siglo XX, pero no tenemos que hacerlo. La misma tecnología que nos hace la vida más fácil y más productiva también se puede utilizar en contra de nosotros. La infraestructura digital en la cual nos basamos en el trabajo y en el juego es frágil y puede ser objetivo de los criminales, gobiernos extranjeros, los agentes no estatales, e inclusive en nutjobs con resentimiento.
Estas nuevas amenazas incluyen, pero no se limitan a:
  • La ciberdelincuencia
  • Guerra cibernética patrocinada por el Estado
  • El mal uso de la tecnología de vehículos autónomos
  • Violaciones a la privacidad
  • Abusos de vigilancia de masas
  • El uso de comunicaciones seguras para las actividades criminales / terroristas
Todos representan un serio desafío y la industria está teniendo problemas para mantenerse. Mi argumento es simple: Nosotros ya no tenemos que desarrollar una tecnología innovadora para obtener una ventaja en las luchas geopolíticas, pero vamos a seguir desarrollando tecnologías y métodos para hacer frente a las nuevas amenazas y problemas. Es un círculo vicioso, ya que estas nuevas amenazas son posibles gracias a nuestra dependencia de las comunicaciones digitales y la amplia disponibilidad de diversas tecnologías que pueden ser empleadas por las organizaciones hostiles e individuales.
Una nueva generación de amenazas emergentes está reuniendo una vez más líderes de la industria y gobiernos en torno a una causa común
Una nueva generación de amenazas emergentes está reuniendo una vez más líderes de la industria y gobiernos en torno a una causa común.
La ciberdelincuencia se asocia generalmente con el robo de identidad y fraude de tarjetas de crédito, pero está ya no se limita a estos campos. El advenimiento de canales seguros de comunicación ha permitido a los delincuentes en expandirse a nuevos nichos. La escena ha recorrido un largo camino desde las hazañas románticas de Steve Wozniak. Algunos ofrecen la piratería de alquiler, otros están dispuestos a acoger todo tipo de contenido ilícito, sin hacer preguntas. Algunos grupos se especializan en el lavado de dinero, bazares de drogas darknet, y así sucesivamente. La amenaza más grande con esta nueva generación de la ciberdelincuencia es que ya no se tiene que poseer muchas habilidades para involucrarse. A medida que madura la delincuencia informática, distintos grupos se especializan en diferentes actividades, y se pueden contratar.
La guerra cibernética patrocinada por el Estado constituye una seria amenaza a la infraestructura, los sistemas financieros y la seguridad nacional. Sin embargo, no hay realmente mucho que un individuo puede hacer frente a estas amenazas, por lo que no vale la pena perder tiempo en ellos en este post. Otra forma de guerra económica parece privar a una nación o región de conexión a Internet. Ya ha sucedido antes, a veces por accidente, otras veces por decreto del gobierno y de la acción del enemigo.
Los drones comerciales no tienen mucho en común con sus homólogos militares. Su gama y su carga útil son muy limitadas, y mientras un drone militar no tripulado, por lo general se puede perder el tiempo en un área por horas en extremo, la resistencia de los drones no tripulados de aficionados se limita a minutos en lugar de horas. Esto no quiere decir que no se pueden utilizar para el crimen; aún pueden invadir la privacidad de alguien, contribuir al contrabando de drogas a través de una frontera, o inclusive en llevar explosivos. Los vehículos autónomos están todavía en su infancia, por lo que no sienten la necesidad de discutir la miríada de preguntas que elevarán.
La privacidad sigue siendo una de las mayores preocupaciones relacionadas con Internet, expresadas por la persona promedio. Esto es comprensible; hemos pasado gran parte de nuestras vidas diarias dedicándolas a la esfera digital, poniendo nuestra privacidad en riesgo. La gente ni siquiera tiene que estar orientada específicamente en tener su privacidad y su integridad personal comprometida. La mayoría de los datos que abren paso en línea se liberan en forma de depósitos masivos después de un fallo de seguridad que afecta a muchos, si no todos, los usuarios de un servicio de una línea en particular. La gente va a seguir exigiendo una mayor privacidad, ya su vez los clientes demandarán una mayor seguridad de los ingenieros de software (que no son trabajadores de milagro y no pueden garantizar la absoluta seguridad y privacidad).
La vigilancia masiva se realiza generalmente por los gobiernos y no debe representar una amenaza para el ciudadano medio o negocio. Sin embargo, sigue siendo una amenaza potencial, ya que puede ser objeto de abuso para los trabajadores descontentos, gobiernos extranjeros, o por medio de las violaciones de datos. El otro problema es el coste enorme para el contribuyente; la vigilancia masiva no es barata y vamos a seguir viendo más de ella.
La mayoría de los gobiernos no se molestan con los programas de vigilancia y de metadatos en masa si no se enfrentan a amenazas muy reales. La misma tecnología desarrollada para mantener nuestras comunicaciones y actividades en línea privada puede ser objeto de abuso por todo tipo de personas no nos gustaría encontrarnos en un callejón oscuro. La lista incluye a los sindicatos del crimen multinacional, terroristas e insurgentes. Sin embargo, no toda esta comunicación debe ser cifrada y segura. El punto de la propaganda es para que sea ampliamente disponible para cualquier persona, el Internet ha dado a cada chiflado un teléfono inteligente y el mayor megáfono en la historia, con un alcance global, de forma gratuita. Puedes utilizar el Internet para reunir un millón de personas en torno a una buena causa en cuestión de días, pero los mismos principios se pueden aplicar a una mala causa. Si el público objetivo son las personas que desean unirse a un culto de la muerte con una inclinación por banderas negras, no necesitas un millón de personas, sólo unas pocas docenas.

La diferencia Entre la Ciencia y la Ciencia Ficción

A pesar de su inteligencia, los autores de la ciencia ficción que ayudaron a configurar la cultura popular en el siglo XX no vieron el futuro real que viene. Ellos no previeron exactamente el Internet, por no hablar de su profundo impacto en la sociedad.
Sentimos estallar tu burbuja, pero Terminators en Inteligencia Artificial (IA) aún no son una amenaza, y no la serán en el corto plazo. Las amenazas reales son más humildes, pero eso no quiere decir que podamos darnos el lujo de ignorarlas. No es necesario un Terminator para crear el caos, todo lo que se necesita es un par de líneas de código realmente desagradables que puedan alterar la infraestructura, causando todo tipo de problemas. No es necesario un autómata super-inteligente del futuro para causar daños. Dado que eBay no lleva Terminators, ya que es mucho más fácil que usar un drone fuera de la plataforma, programado para entregar una carga útil con un objetivo específico: las drogas a un traficante, o una carga explosiva a un VIP.
Pero estas no son las mayores amenazas, son amenazas potenciales simples: algo para un guión de Hollywood, no para un blog de tecnología.
Las amenazas son reales criminales en naturaleza, pero tienden a permanecer en el cyber real. No tienes que mover físicamente nada para mover el dinero sucio y la información en línea. La aplicación de la ley ya está teniendo dificultades para mantenerse al día con los delitos informáticos, que parecen estar empeorando. Si bien es cierto que la tasa de criminalidad en los países desarrollados está disminuyendo, estas estadísticas no pintan el cuadro completo. Hace unas semanas, la Oficina Británica de Estadísticas Nacionales (ONS) informó de un aumento del doble de la tasa de criminalidad de Inglaterra y Gales, un total de más de 11.6 million ofensas. Además la tasa de criminalidad tradicional continuó cayendo, pero las estadísticas indicaban 5,1 millones de casos de fraude en línea. El costo de la delincuencia física está bajando, pero el costo de la delincuencia informática está empezando a ponerse al día. Creo firmemente que la industria tendrá que hacer más para reforzar la seguridad, y los gobiernos tendrán que invertir en seguridad en línea y la prevención del delito, así.
En caso de que estés interesado en la ficción distópica y no encuentras a las amenazas criminales emocionantes, otro desarrollo aterrador sería la monopolización de datos: Un proceso en el que gigantes de la industria mantendrían una ventaja de competencia posible gracias a su amplia base de usuarios, como para hacer a la demás competencia sin sentido, y anulándola de este modo.
Sí, soy consciente de lo que los Terminators harán para un futuro más intrigante y para un blog más interesante, pero no estamos allí todavía.

Saludos.

Configura mikrotik a través 2da. conexión de Internet


Archivos o Ficheros: Lectura de un archivo de texto

 https://www.youtube.com/watch?v=ksnBUo-08Uw

martes, agosto 23, 2016

Nuevas funcionalidades en Microsoft SQL Server 2016

Amigos en esta oportunidad estaré dictando una charla Sobre Nuevas funcionalidades en Microsoft SQL Server 2016, están todos invitados.



Link ==> https://www.facebook.com/tecnologiaVG/photos/a.671873352836045.1073741828.628437377179643/1161199717236737/?type=3&theater

Saludos.

jueves, junio 30, 2016

Init.js: Una guía de los Por Qué y Cómos en el conjunto de tecnologías de JavaScript

La Historia

Entonces, tú y tu cofundador tienen esta genial idea para un negocio, ¿verdad?
Has estado agregando características en tu cabeza.
Frecuentemente, le preguntas a tus potenciales clientes sus opiniones, y todos ellos la aman.
Ok, entonces la gente la quiere. Hay hasta un poco de dinero para hacer. Y la única razón por la cual ellos no pueden obtenerla es porque no las has implementado—todavía.
Entonces, finalmente, te sientas un día y dices “¡Hagámoslo!”. Pronto, estás tratando de averiguar cómo aplicar la lógica de negocio de tu aplicación, la funcionalidad asesina que va a llevar adelante al producto: tienes una idea de cómo hacerlo, y ahora sabes que puedes hacerlo.
“¡Listo!¡Funciona!” dices. ¡Tu prueba de concepto es un éxito! Todo lo que queda por hacer es empaquetarlo en una aplicación web.
“Ok, hagamos el sitio”, dices.
Y entonces, te das cuenta de la verdad: necesitas elegir un lenguaje de programación; necesitas elegir una plataforma (moderna); necesitas elegir algunos frameworks (modernos); necesitas configurar (y comprar) espacio, base de datos y proveedores de alojamiento; necesitas una interfaz de administración; necesitas un sistema de permisos; necesitas un administrador de contenidos.
Quieres ser escueto, quieres ser ágil. Quieres usar tecnologías que te ayudaran a tener éxito en el corto-y largo-plazo. Y no son siempre fáciles de elegir
Tienes que tomar decenas y decenas de decisiones de arquitectura . Y quieres tomar las correctas: quieres usar tecnologías que te permitan desarrollo rápido, iteración constante, máxima eficiencia, velocidad, robustez y más. Quieres ser escueto, quieres ser ágil. Quieres usar tecnologías que te ayudaran a tener éxito en el corto-y largo-plazo. Y no son siempre fáciles de elegir.
“Estoy abrumado”, dices, mientras te vas sintiendo abrumado. Tu energía no es la misma de antes. Tratas de encajar las piezas, pero es demasiado trabajo.
Tu prueba de concepto se marchita y muere lentamente.

La Propuesta

Luego de abandonar toneladas de ideas de esta forma, decidí diseñar una solución. La llamo el proyecto ‘Init’ (Inicio)(ó init.js).
El corazón de la idea es tener un simple proyecto que inicie todos los demás, dejar que el desarrollador o el fundador técnico tomen esas decisiones al mismo tiempo y recibir una plantilla apropiada para empezar basada en esas decisiones. Se lo que van a decir los detractores, “Una solución no puede aplicarse a todos los problemas” (Odiadores odiarán). Y puede que estén en lo cierto. Pero podemos hacer nuestro mejor esfuerzo para crear una solución aproximada, y creo que Init se acerca bastante.
Para lograr mejor este objetivo, tenemos que tener algunas ideas claves en mente. Cuando estaba desarrollando Init, consideré:
  • Componentes
    La modularización es una característica clave de cualquier sistema ya que te permite reusar componentes de software a través de distintos proyectos—lo cual es el principal objetivo de Init. Pero la modularización también viene con una “reemplazabilidad” por producto, la cual será nuestra mejor aliada a la hora de atacar varios tipos de problemas con “casi” la misma solución.
  • Facilidad de Desarrollo
    Para algunos problemas, en algún lado hay una mejor solución escrita en [Brainf*ck](https://en.wikipedia.org/wiki/Brainfuck). ó jodecerebros). Pero implementar esa solución (en Brainf*uck) sería casi imposible de escribir, y mucho menos de leer. Te costaría tiempo y una enorme cantidad de esfuerzo. En general, deberías usar lenguajes y plataformas que hagan al desarrollo fácil, y no difícil para tí (o alguien que puede trabajar con él más tarde).
  • Comunidad
    Cualquier plataforma que elijas, asegúrate que tenga una gran comunidad, y una que te pueda ayudar con los problemas más comunes y con los que no lo son tanto. Recuerda: jQuery puede no ser la librería másrápida, la más limpia, o la más elegante—pero es un ganador sólo por su comunidad.
Teniendo estos objetivos en mente, voy a mostrarte como hice mis propias decisiones al crear Init.
En su núcleo, Init se aprovecha del paradigma ‘full-stack JavaScript’ (algunas personas se refieren a él, o a una parte de él, como el MEAN Stack). Al trabajar con este conjunto, Init es capaz de usar solamente un sólo lenguaje mientras crea un ambiente increíblemente flexible y con todas las funciones para desarrollar aplicaciones web. En resumen, Init te permite usar JavaScript no solamente para desarrollo del lado cliente y servidor, pero también para construir, testear, maquetar, y más.
Pero bajemos un poco la velocidad y preguntémonos: ¿es realmente una buena idea usar JavaScript?

Por qué elegí JavaScript

Soy desarrollador web desde 1998. Por esas épocas usabamos Perl para la mayoría de nuestro desarrollo del lado del servidor, y aún desde esos tiempos teníamos JavaScript del lado del cliente. Las tecnologías web del lado servidor han cambiado inmensamente desde entonces: fuimos a través de oleada tras oleada de distintas tecnologías y lenguajes cómo PHP, ASP, JSP, .NET, Ruby, Python, solo por nombrar algunas. Los desarrolladores comenzaron a darse cuenta que usando dos distintos lenguajes para ambientes cliente y servidor estaba complicando las cosas. Los intentos iniciales para unificar bajo un mismo lenguaje intentaban crear componentes cliente del lado del servidor y compilarlos en JavaScript. Esto no funcionaba como se esperaba y muchos de esos proyectos fallaron (por ejemplo, ASP MVC reemplazando los formularios web de ASP.NET, y podría decirse queGWT será reemplazado por Polymer). en un futuro cercano). Pero era una excelente idea, en esencia: un lenguaje único en el cliente y el servidor, permitiéndonos reusar componentes y recursos (esta es la clave:recursos).
La respuesta era simple: usar JavaScript en el servidor.
De hecho, JavaScript nació con JavaScript Server Side en Netscape Enterprise Server, pero el lenguaje simplemente no estaba listo en esa época. Luego de años de prueba y error, Node.js finalmente emergió, lo cual no solo puso a JavaScript en el servidor, pero además promovió la idea de programación no-bloqueante, cambiando la forma en la que escribimos “fread”(I/O) para siempre (lee más aquí.
En una oración: la programación no-bloqueante apunta a poner tareas que consumen tiempo a un lado, usualmente especificando que se debería hacer una vez que estas tareas se hayan completado, y permitiendo que el procesador maneje otros pedidos mientras tanto.
Pero esas ideas no eran nuevas—entonces, ¿por que se volvieron tan populares con Node.js? Simple, la programación no-bloqueante puede ser alcanzada de distintas formas. Tal vez la más fácil es usar callbacks y un evento en bucle. En la mayoría de los lenguajes, esa no es una tarea fácil: mientras que los ‘callbacks’ son una característica común en algunos lenguajes, un evento en bucle no lo es y usualmente te encuentras aferrándote a librerías externas (por ejemplo: Python, con Tornado). Pero en JavaScript, los callbacks son construidos dentro del lenguaje, como también el evento en bucle, y casi cualquier programador que haya incursionado en JavaScript está familiarizado con ellos (o al menos los han usado, aunque no entiendan del todo que significa un evento en bucle). De repente, cada una de las startup en el Planeta Tierra podía reusar desarrolladores (por ej., recursos) tanto en el lado cliente cómo en el lado del servidor, resolviendo el problema de “Se necesita Gurú Python”.
De repente, cada una de las startup en el Planeta Tierra podía reusar desarrolladores (por ej., recursos) tanto en el lado cliente cómo en el lado del servidor, resolviendo el problema de “Se necesita Gurú Python”.
Entonces, ahora tenemos una plataforma increíblemente rápida (gracias a la programación no-bloqueante) con un lenguaje de programación que es increíblemente fácil de usar (gracias a JavaScript). Pero, ¿Es suficiente? ¿Perdurará? Estoy seguro que JavaScript va a tener un importante lugar en el futuro. Déjame decirte por qué:
  • Programación Funcional
    JavaScript fue el primer lenguaje de programación que llevó el paradigma funcional a las masas (por supuesto, Lisp llegó primero, pero la mayoría de los desarrolladores nunca han construido una aplicación en Lisp lista para ser usada en producción). Lisp y Self, influencias principales de Javascript, están llenos de ideas innovadoras. Esas ideas pueden liberar nuestras mentes para explorar nuevas técnicas, patrones y paradigmas. Y todos ellos llevan a JavaScript. Mira monadscodificación Church, o incluso (para un ejemplo más práctico) la colección de funciones](http://underscorejs.org/#collections), de Underscore.js las cuales pueden salvarte líneas y líneas de código.
  • Objetos Dinámicos y herencia Prototipada
    La programación orientada a objetos sin clases (y sin las interminables herencias de clases) permite rápido desarrollo (crear objetos, agregar métodos y usarlos) pero, lo más importante, reduce el tiempo de refactorización durante tareas de mantenimiento dejando que el desarrollador modifique instancias de objetos en vez de clases. Esta velocidad y flexibilidad pavimenta el camino para el desarrollo rápido.
  • JavaScript es Internet
    JavaScript fue diseñado para Internet, ha estado aquí desde el principio, y no va a irse. Todos los intentos por destruirlo han fallado, mira, por ejemplo, la caída de los Applets Java, el reemplazo de VBScript de Microsoft, TypeScript (que compilaba a JavaScript), y la caída de Flash en manos del mercado móvil y HTML5. Es imposible reemplazar Javascript sin romper millones de páginas web, así que nuestro objetivo a largo plazo debería ser el de mejorarlo. Y no hay nadie mejor para esa tarea que el Technical Committee 39 de ECMA.
    Ok, alternativas a JavaScript nacen todos los días, cómo CoffeeScriptTypeScript, y los los millones de lenguajes que compilan a JavaScript. Esas alternativas pueden ser útiles para etapas de desarrollo (por medio de mapeos de código fuente), pero fallarán al tratar de suplantar JavaScript a largo plazo por dos razones: sus comunidades nunca serán más grandes, y sus mejores funcionalidades serán adoptadas por el script de ECMA (por ej., JavaScript). JavaScript no es como un lenguaje ensamblador: es un lenguaje de programación de alto nivel con código fuente que puedes entender—entonces deberías entenderlo.
Ahora, gracias al proyecto Esprima, puedes crear tus propias herramientas para jugar con el código fuente, modificándolo, cambiando su estilo, agregando comentarios, instrumentando, y todo de tipo de cosas que puedas imaginar al jugar con el Árbol de Sintaxis Abstracta de tu programa como si estuvieses jugando con un Árbol DOM.

JavaScript de extremo a extremo: Node.js y MongoDB

Entonces, esas son las razones para usar JavaScript. Ahora, voy a usar JavaScript como una razón para usar Node.js y MongoDB.
  • Node.js
    Node.js es una plataforma para construir aplicaciones de red rápidas y escalables—eso es básicamente lo que dice el sitio de Node.js. Pero Node.js es más que eso: es el entorno de ejecución preferido por cualquier aplicación con acceso de E/S en JavaScript. Incluso si no planeas escribir tu aplicación del servidor principal con Node.js, puedes usar herramientas creadas construidas encima de Node.js para mejorar tu proceso de desarrollo. Por ejemplo: Mocha.js para unit testing, Grunt.js para tareas de construcción automatizadas, o incluso Brackets para completar edición de código.
    Entonces, si vas a escribir aplicaciones de JavaScript para servidor o cliente, deberías familiarizarte con Node.js, porque vas a necesitar usarlo diariamente. Hay algunas interesantes alternativas), pero ninguna de ellas llega siquiera al 10% de la comunidad de Node.js.
  • MongoDB
    MongoDB es una base de datos NoSQL basada en documentos que usan JavaScript como su lenguaje de consultas, permitiendo completar de extremo-a-extremo la plataforma JavaScript. Pero esa no es siquiera la razón principal para elegir esta base de datos.
    MongoDB es una base de datos sin esquema que permite persistir tus objetos de una manera flexible y por lo tanto adaptarse más rápidamente a los cambios en los requisitos. Además, es altamente escalable y basado en map-reduce, lo cual lo hace adecuado para aplicaciones con muchos datos. MongoDB es tan flexible que puede ser usado como una base de datos de documentos sin esquema, un almacén de datos relacional (aunque le faltan transacciones),o incluso almacenamiento de clave-valor para respuestas de caché.

Modularización de Servidor con Express.js

Modularización en el lado del servidor nunca es fácil. Pero con Express.js (y Connect.js) vino la idea de‘middleware’(ó software intermedio). En mi opinión, middleware es la mejor forma de definir componentes en el servidor. Si quieres compararlo con un patrón conocido, se acerca bastante a los tubos y filtros.
La idea básica es que tu componente es parte de una tubería. La tubería procesa el pedido (entrada) y genera una respuesta (salida), pero tu componente no es responsable por la respuesta completa. En cambio, solo modifica lo que necesita y luego delega hacia la otra pieza de la tubería. Cuando la última pieza de la tubería termina su proceso, la respuesta se envía al cliente.
Nos referimos a estas ‘piezas de tubería’ como ‘middleware’. Claramente, podemos crear dos tipos demiddleware:
  • Intermedios: Esos que procesan el pedido y la respuesta, pero no son del todo responsables por la respuesta en sí, entonces delegan al siguiente middleware.
  • Finales: Esos que toman la responsabilidad por completo en la respuesta final. Ellos procesan y modifican el pedido y la respuesta, pero no necesitan delegar al siguiente middleware. En la práctica, se recomienda que delegues a un siguiente middleware, de todas maneras, para permitir flexibilidad en la arquitectura (por ej., agregar más middleware después), aunque ese middleware no exista (en ese caso la respuesta irá directamente al cliente)

Como ejemplo concreto, considera un componente ‘usuario administrador’ en el servidor. En términos de middleware, tendríamos tanto finales como intermediarios. Para nuestros finales, tendríamos características tales como crear un usuario y listar usuarios. Pero antes que podamos realizar esas acciones, necesitamos nuestros intermediarios para autenticación (ya que no queremos pedidos que creen usuarios sin autenticar). Una vez que creamos estos intermediarios para autenticación, podemos simplemente conectarlos en cualquier lado que queramos para convertir una característica sin autenticación existente en una con autenticación.

Aplicaciones de una sóla página

El proyecto Init enfoca en crear aplicaciones de una sóla página (SPAs-Single-Page Applications). Muchos desarrolladores web se han tentado más de una vez en probar construir SPAs. Desarrollé usando varias (principalmente propietarias), y puedo decir con confianza que son simplemente el futuro de las aplicaciones web. ¿Alguna vez comparaste una SPA con una aplicación web regular en una conexión móvil? La diferencia de respuesta es de decenas de segundos.
¿Alguna vez comparaste una SPA con una aplicación web regular en una conexión móvil? La diferencia de respuesta es de decenas de segundos.
Las SPA son el futuro de la web—¿entonces por que harías tu producto en un formulario antiguo? Un argumento común que escucho es que la gente está preocupada por el SEO. Pero si manejas las cosas correctamente, esto no debería ser un problema: Google mismo tiene un muy buen tutorial sobre como hacerlo, y hay muy buenos comentarios aquí también.

MV* del lado del cliente con Backbone.js, Marionette.js y Twitter Bootstrap

Mucho se ha dicho acerca de los MVC* frameworks para SPAs. Es una decisión complicada, pero voy a decir que el top 3 son Backbone.jsEmber.js, y Angular.js.
Los tres son bien considerados. ¿Pero cual de ellos es el mejor para tí?
Desafortunadamente, tengo que admitir que tengo una experiencia muy limitada con Angular.js, así que voy a dejarlo fuera de esta discusión. Ahora, Ember.js y Backbone.js representan dos maneras distintas de atacar el mismo problema.
Backbone.js es minimalista, simplista y te ofrece lo suficiente para crear una simple SPA. Por otro lado, Ember.js es un framework completamente profesional para crear SPAs. Tiene más adornos, pero también una curva de aprendizaje más grande.
Dependiendo del tamaño de tu aplicación, la decisión puede ser tan fácil como mirar el ratio de featuresUsed/featuresAvailable(características Usadas/Disponibles), lo cual te dará una gran pista.
En el caso de Init, quería cubrir la mayoría de los escenarios, así que elegí Backbone.js para creación fácil de SPAs, con Backbone.Marionette.View para modularización. De esta forma, cada componente es una simple aplicación, y la aplicación final puede ser tan compleja como queramos que sea.
Estilizar es también un desafío, pero podemos, de vuelta, contar con frameworks para rescatarnos. Para CSS, no hay nada mejor que Twitter Bootstrap, que ofrece un completo set de estilos que ya están listos para usar y sonfáciles de personalizar.
Booststrap fue creado usando el lenguaje LESS que es de código abierto, así que podemos modificarlo si así lo necesitasemos. Viene con una tonelada de controles de usabilidad que están bien documentados en el sitio de Bootstrap. Además, hay un modelo de personalización que te permite crear tus propios controles. Definitivamente es el hombre para este trabajo.

Mejores prácticas: Grunt.js, Mocha.js, Chai.js, RequireJS y CoverJS

Finalmente, deberíamos definir algunas de nuestras mejores prácticas, y buscar en como Init puede ayudarte a implementarlas y mantenerlas. Nuestra solución está centrada en varias herramientas, que están basadas en Node.js.
  • Mocha.js and Chai.js:
    Estas herramientas te permiten mejorar tu proceso de desarrollo aplicando TDD o BDD, proveyendo la infraestructura para organizar tus tests unitarios y un lanzador para correrlos automáticamente.
    Hay miles de frameworks para test unitarios para JavaScript. ¿Entonces, por que usar Mocha.js? La respuesta corta: es flexible y completo.
    La respuesta larga: tiene dos características importantes (interfaces, reporters) y una ausencia importante (assertions). Déjenme explicarles.
    • Interfaces: tal vez estés acostumbrado a los conceptos de TDD de suites y tests unitarios, o tal vez prefieras ideas BDD de especificaciones de comportamiento con “describe” y “it should”. Mocha.js te permite usar los dos acercamientos.
    • Reporters: correr tu test generará reportes de resultados, y puedes darle formato a esos resultados usando varios reporters. Por ejemplo, si tienes que alimentar un servidor de Integración Continua, puedes encontrar un reporter para hacer exactamente eso.
    • Falta de una librería de assertions: : lejos de ser un problema, Mocha.js fue diseñado para dejarte usar la librería de assertions que prefieras, ofreciendo más flexibilidad. Hay muchas opciones, pero ahí es donde Chai.js entra en acción.
    Chai.js es una librería de assertions flexible que permite usar cualquiera de los tres más importantes estilos de assertions:
    • Assert: Estilo de assertion clásico de la vieja escuela. Ej.:
        assert.equal(variable, ”valor”);  
      
    • Expect: Tipo de assertion encadenable más comúnmente usado en BDD. Ej.:
        expect(variable).to.equal(“valor”);
      
    • Should: También usado en BDD, pero prefiero Expect porque Should porque suena repetitivo con la especificación de comportamiento _’it _(“should do something..”-” eso debería hacer algo”). Ej.:
        variable.should.equal(“valor”);
      
    Chai.js se combina perfectamente con Mocha.js. Usando solamente estas dos librerías, puedes escribir tus test en TDD, BDD, o cualquier estilo imaginable.
  • Grunt.js:
    Grunt.js permite automatizar tareas de construcción, cualquier cosa desde simples archivos concatenados copiados y pegados, a plantillas precompiladas, estilo compilado de lenguaje (por ej., SASS y LESS), test unitario (con mocha.js), linting y compresión de código (ej., con UglifyJS o Closure Compiler). Puedes agregar tu propia tarea automatizada a Grunt, o buscar en el registro de Grunt, donde hay cientos y cientos de plugins disponibles (de vuelta, usando herramientas con grandes comunidades detrás paga bien). Grunt también puede monitorear tus archivos y disparar acciones cuando estos son modificados.
  • RequireJS:
    RequireJS puede sonar como otra forma de cargar modulos con AMD, pero puedo asegurarte que es mucho más que eso. Para entender por qué, primero debemos mencionar la idea del namespacing de modulos (ej., demo.views.hola), lo que evita contaminar el namespace global envolviendo cada módulo en su propio namespace. El problema es, estos módulos no son reusables: si modificas el namespace de una ‘instancia’, estás modificando el namespace de todas las ‘instancias’. En contraste con eso, RequireJS permite definir módulos reusables desde el principio. (Además, te ayudará a adoptar Dependency Injection para evitar que tus modulos accedan variables globales).
  • CoverJS:
    Cobertura de código es una medida métrica para evaluar tu testing. Como el nombre implica, te dice cuanto código está cubierto en tu conjunto de tests actual. CoverJS mide la cobertura de código de tus tests instrumentando declaraciones (en vez de líneas de código cómo JSCoverage) y generando una versión instrumentada de tu código. También genera reportes para alimentar tu servidor de integración continua.

Usando _Branches_ (_ramas_) para alternar características

Cuando empecé Init, necesitaba una manera para que los usuarios activen y desactiven varias características que podrían llegar a querer en su proyecto. Decidí tomar un enfoque radical con el sistema de ramas de git para implementar esta funcionalidad.
En esencia, cada rama representa una característica o funcionalidad que un usuario podría querer incluir. Si estás empezando un proyecto desde el principio, empieza por la rama mínima que necesitas, y luego agrega otras tecnologías fusionando la rama con las otras deseadas. Por ejemplo, digamos que quieres empezar tu proyecto con Backbone.js y Marionette.js. Bueno, puedes empezar en la rama Backbone.js y fusionarla con la rama Marionette, continuando desde ahí para cada pedazo de funcionalidad que quieras agregar.
Por ahora, la idea de fusionar para agregar funcionalidad puede solo ser usada para plantillas de tecnología (ej., Backbone, Node, Express). Pero en el futuro, serás capaz de alternar entre back-end (ej., desde MongoDB a Postgres) e implementaciones del lado cliente.

Empieza un proyecto con Init y haz un deploy en Heroku hoy

Nunca ha habido una manera más fácil de empezar un proyecto. Dirígete al repositorio de GitHub, fijate la rama con los últimos commits (ahora mismo es usermanager, aunque esto puede cambiar en el futuro) y entonces:
  1. Crea un directorio para tu proyecto (o usa uno existente).
  2. Crea tu repositorio con “git init” (o usa un repositorio existente)
  3. Agrega un servidor remoto con Init
     git remote add init git: //github.com/picanteverde/init.git
    
  4. Descarga la rama que quieras
    git pull init usermanager
    
  5. Obtén el archivo de procesos de Heroku
     git pull init heroku-webprocess
    
  6. Con el Heroku Toolbelt instalado, crea una aplicación
     heroku create
    
  7. Haz un push a la rama master a Heroku
     git push heroku master
    
  8. Visita tu aplicación en funcionamiento en Heroku!
Ahora puedes empezar a desarrollar tu característica asesina con solo unas líneas de código. No solo eso, sino que estarás desarrollando con las últimas y más eficientes tecnologías en una suite de desarrollo lo más automatizada posible.
Espero que puedas usar Init para comenzar tu próxima gran idea. Recuerda Revisar el repositorio de Init para ver correcciones y características—su desarrollo es bastante activo, y espero con ansias escuchar sus comentarios.

Contenido traducido por Pablo Fabregat, miembro de TransBunko, un mercado de traducciones técnicas.

Fuente: https://www.toptal.com/javascript/init-js-una-gu-a-de-los-por-qu-y-c-mos-en-el-conjunto-de-tecnolog-as-de-javascript/es
Saludos.

¿Qué es un Algoritmo?

Más información ==>  https://m.facebook.com/story.php?story_fbid=779713015547334&id=332220556963251