Mostrando las entradas con la etiqueta Artículos. Mostrar todas las entradas
Mostrando las entradas con la etiqueta Artículos. Mostrar todas las entradas

jueves, 28 de julio de 2016

Artículo - Silicon Valley

Silicon Valley

La misión principal de este blog es la cultura en computación, programación, sistemas y TI en general, es por eso que he elaborado este artículo sobre uno de los sitios más importantes del mundo donde se han desarrollado durante décadas muchas empresas (Start-ups) y muchos productos o servicios innovadores, a continuación un resumen sobre Silicon Valley, extraído de diferentes fuentes: Wikipedia, SiliconValley.com, GoodReads.com, YouTube, etc.

1. Ubicación e Importancia (fuente: Wikipedia)

Silicon Valley o Valle de Silicio es el nombre que recibe la zona sur del Área de la Bahía de San Francisco, en el norte de California, Estados Unidos.4 La región cuyo nombre proviene del Valle de Santa Clara, incluye la mitad sur de la Península de San Francisco, abarcando aproximadamente desde Menlo Park hasta San José y cuyo centro se situaría en Sunnyvale. Sin embargo, con el rápido aumento de la cantidad de puestos de trabajo relacionados con la tecnología en la zona metropolitana de San Francisco, las fronteras tradicionales de Silicon Valley se han expandido hacia el norte incluyendo el condado de San Mateo y la ciudad de San Francisco, como también partes del condado de Marin.

El Silicon Valley aloja muchas de las mayores corporaciones de tecnología del mundo y miles de pequeñas empresas en formación (start-ups). Originalmente la denominación se relacionaba con el gran número de innovadores y fabricantes de chips de silicio fabricados allí, pero definitivamente acabó haciendo referencia a todos los negocios de alta tecnología establecidos en la zona; en la actualidad es utilizado como un metónimo para el sector de alta tecnología de los Estados Unidos (a la manera de Hollywood para el cine estadounidense).

A pesar del desarrollo de otros centros económicos de alta tecnología en Estados Unidos y por el mundo, Silicon Valley continúa siendo el centro líder para la innovación y desarrollo de alta tecnología, recibiendo un tercio (1/3) del total de la inversión de capital de riesgo en Estados Unidos.

2. Historia (fuente: Wikipedia)

La ubicación de las industrias de alta tecnología en el valle se debió, en gran medida, a William Shockley y Frederick Terman.

Terman, profesor de la Universidad de Stanford, consideró que una vasta zona sin utilizar de propiedad de la universidad sería perfecta para el desarrollo inmobiliario e intelectual y estableció un programa para incentivar a los estudiantes graduados a quedarse allí, proveyéndoles de capital de riesgo. Uno de los principales éxitos en la historia del programa fue que logró convencer a dos graduados: William Hewlett y David Packard, quienes conformarían la empresa Hewlett-Packard, la cual se convertiría en una de las primeras firmas tecnológicas que no estaban directamente relacionadas con la NASA o la Marina estadounidense.

En 1951 el programa se amplió nuevamente, creando el "Parque Industrial de Stanford" (Stanford Industrial Park en inglés), que consistía en una serie de pequeños edificios industriales que eran alquilados a muy bajo coste a compañías técnicas. En 1954 se instituyó The Honors Cooperative Program, actualmente llamado coop, para permitirle a los empleados a tiempo completo de las compañías obtener títulos universitarios estudiando en un régimen de media jornada. Las primeras compañías firmaron acuerdos de cinco años en los cuales establecían que pagarían el doble de la matrícula por cada estudiante para cubrir los gastos. Hacia mediados de los 50 la estructura de lo que posteriormente permitiría la creación del "valle" se encontraba en una etapa ascendente gracias a los esfuerzos de Terman.

Fue en esta atmósfera en la que un antiguo californiano decidió mudarse allí. William Shockley, quien había abandonado Bell Labs en 1953 por un desacuerdo sobre la forma en que se había presentado el transistor al público, ya que debido a los intereses de patentes, se relegó su nombre a un segundo plano en favor de los coinventores John Bardeen y Walter Houser Brattain. Tras divorciarse de su mujer, volvió al Instituto de Tecnología californiano donde se graduó en Ciencias, pero se trasladó a Mountain View para crear la empresa Shockley Semiconductor como parte de Beckman Instruments y vivir más cerca de su madre.

A diferencia de otros investigadores que utilizaban germanio como material semiconductor, Shockley creía que el silicio era un mejor material para fabricar transistores. Shockley se propuso mejorar el transistor con un diseño de tres elementos (hoy se le conoce como el diodo Shockley) que obtendría éxito comercial, pero cuyo diseño era considerablemente más difícil de construir que el diseño convencional. A medida que el proyecto pasó por varias dificultades, Shockley se volvió cada vez más paranoico. Exigió que los empleados se sometieran a un detector de mentiras, anunció sus salarios públicamente y, en general, se enemistó con todo el mundo, y en 1957, Shockley decide finalizar el trabajo relacionado con el transistor de silicio, todos factores que ayudaron a que en 1957, ocho de los ingenieros más brillantes, que él mismo había contratado, lo abandonaran para formar la compañía Fairchild Semiconductor. Shockley los llamaba los "ocho traidores". Dos de los empleados del grupo original de Fairchild Semiconductor, Robert Noyce y Gordon Moore, a su vez luego fundarían Intel.

Durante los años siguientes este hecho se repetiría varias veces; a medida que los ingenieros perdían el control de las compañías que crearon al caer en manos de directivas exteriores, las abandonaban para formar sus propias empresas. AMD, Signetics, National Semiconductor e Intel surgieron como vástagos de Fairchild o, en otros casos, como vástagos de vástagos.

A comienzos de 1970, toda la zona estaba llena de compañías de semiconductores que abastecían a las compañías de computadores y estas dos, a su vez, a las compañías de programación y servicios. El espacio industrial era abundante y el alojamiento aún barato. El crecimiento se vio potenciado por el surgimiento de la industria de capitales de riesgo en Sand Hill Road que fundó Kleiner Perkins en 1972; la disponibilidad de estos capitales estalló tras el éxito de 1300 millones de dólares por la OPA (oferta pública de acciones) de Apple Computer en diciembre de 1980.

3. Ciudades de Silicon Valley (por principales empresas)

- Palo Alto: Hewlett-Packard, Xerox, Facebook, VMWare, Pinterest, Tesla Motors

- San José: eBay, PayPal, Adobe Systems Inc, Cisco Systems, Sunpower Corp.

- Mountain View: Google, Intuit, LinkedIn, Symantec Corp.

- San Francisco: Twitter, Zynga

- Sunnyvale: Juniper Networks, Yahoo

- Menlo Park: Facebook, Kleiner Perkins Caufield & Byers

- Redwood City: Electronic Arts, Oracle Corp.

- Cupertino: Apple Inc.

- Los Gatos: Netflix

- Santa Clara: Intel Corp.

- Otras Ciudades: Alviso, Atherton, Belmont, Burlingame, Campbell, Foster City, Fremont, Hillsborough, Los Altos, Millbrae, Monte Sereno, Milpitas, Newark, San Carlos, San Mateo, Saratoga, Union City, Woodside.

4. Empresas mas importantes de Silicon Valley (por año de fundación)

- Hewlett-Packard (HP) (1939): Empresa de tecnologías de la información fundada por Bill Hewlett y David Packard en 1939. Tiene 349,600 empleados y un beneficio neto de 7,070 millones de dólares.

- Intel (1968): Compañia tecnológica de semiconductores fundada por Robert Noyce y Gordon Moore en 1968. Tiene 107,300 empleados y un beneficio neto de 11.4 billones de dólares.

- Kleiner Perkins Caufield & Byers (KPCB) (1972): Empresa de capital de riesgo fundada por Eugene Kleiner, Tom Perkins, Frank J. Caufield y Brook Byers en 1972. Tiene personas muy importantes como John Doerr, Raymond J. Lane y Bill Joy (Sun Microsystems).

- Microsoft (1975): Empresa de Software fundada por Bill Gates y Paul Allen en 1975. Tiene 118,584 empleados y un beneficio neto de 13,490 millones de dólares.

- Apple (1976): Empresa de equipos electrónicos y software fundada por Steve Jobs y Steve Wozniak en 1976. Tiene 80,000 empleados y un beneficio neto de 39,510 millones de dólares.

- Oracle (1977): Compañía de software que desarrolla bases de datos y herramientas de programación fundada por Larry Ellison, Ed Oates y Bob Miner en 1977. Tiene 105,000 empleados y un beneficio neto de 3,381 millones de dólares.

- Symantec (1982): Es una compañía de software de seguridad fundada por Gary Hendrix en 1982. En 1990 compra Peter Norton Computing. Tiene 21,500 empleados y un beneficio neto de 878 millones de dólares.

- Adobe Systems (1982): Empresa de Software de edición y video fundada por John Warnock y Charles Geschke en 1982. Tiene 14,154 empleados y un beneficio neto de 987 millones de dólares.

- Electronic Arts (1982): Empresa de Video Juegos fundada por Trip Hawkins en 1982. Tiene 9,370 empleados y un beneficio neto de 76 millones de dólares.

- Intuit (1983): Empresa de software empresarial fundada por Scott Cook y Tom Proulx en 1983.

- Cisco Systems (1984): Empresa de equipos de telecomunicaciones fundada por los esposos Leonard Bosack y Sandra Lerner en 1984. Tiene 74,000 empleados e ingresos de 47,100 millones de dólares.

- SunPower (1985): Compañia de energía solar que diseña y fabrica celdas fotovoltaicas de silicio cristalino de alta calidad, fundada por Richard Swanson en 1985.

- Yahoo (1994): Es una empresa global de medios o sofwtare para Internet fundada por Jerry Yang y David Filo en 1994. Tiene 11,000 empleados y un beneficio neto de 7,520 millones de dólares.

- eBay (1995): Empresa de comercio electrónico fundada por Pierre Omidyar en 1995. Tiene 34,600 empleados e ingresos netos de 1.72 billones de dólares.

- Juniper Networks (1996): Compañia de sistemas de redes y seguridad fundada en 1996. Es la competencia de Cisco sobre todo en Europa.

- Netflix (1997): Empresa de software de entretenimiento fundada por Reed Hastings y Marc Randolph en 1997. Tiene 2,189 empleados y un beneficio neto de 226 millones de dólares.

- Google (1998): Compañia de software para Internet fundada por Serguéi Brin y Larry Page en 1998. Actualmente es subsidiria de Alphabet Inc. la cual tiene 55,419 empleados y un beneficio neto de 14,444 millones de dólares.

- VMWare (1998): Es una empresa de software de virtualización fundada por Diane Greene en 1998. Es una filial de EMC Corporation que a su vez es propiedad de Dell Inc.

- Salesforce (1999): Compañía de computación en la nube fundada en Marc Benioff y Parker Harris en 1999. Tiene 19,000 empleados y ventas por 111 millones de dólares.

- LinkedIn (2002): Empresa de servicios de redes sociales fundada por Reid Hoffman y miembros del equipo de PayPal en el 2002. Este año fué adquirida por Microsoft por 26.2 billones de dólares. Tiene 9,732 empleados y 106 millones de usuarios.

- Tesla Motors (2003): Compañía que diseña, fabrica y vende coches eléctricos, fue fundada por Elon Musk, Martin Eberhard y JB Straubel en el 2003. Tiene 14,000 empleados e ingresos por 4076 millones de dólares.

- Facebook (2004): Empresa de servicios de redes sociales fundada por Mark Zuckerberg en el 2004. Tiene 12,691 empleados y un beneficio neto de 3,688 billones de dólares. Además tiene 1.65 billones de usuarios.

- SolarCity (2006): Empresa proveedor de servicios de energía fundada por Elon Musk en el 2006. Tiene 2,510 empleados.

- Twitter (2006): Compañía de servicios de microblogging fundada por Jack Dorsey, Noah Glass, Biz Stone y Evan Williams en el 2006. Tiene 3,638 empleados e ingresos por 2.21 billones de dólares. Además tiene 332 millones de usuarios.

- Zinga (2007): Empresa de Video Juegos y servicios de redes sociales fundado por Mark Pincus en 2007. Tiene 1,974 empleados e ingresos por 690,410 millones de dólares.

5. Personas mas importantes de Silicon Valley (por año de nacimiento)

- Larry Ellison (1944, USA): Fundador de Oracle Corp.

- T.J. Rodgers (1948, USA): Fundador de Cypress Semiconductor, varias patentes y premios.

- John Chambers (1949, USA): CEO Cisco Systems.

- Paul Otellini (1950, USA): Ex CEO Intel, Junta Directiva Google.

- John Doerr (1951, USA): Kleiner Perkins Caufield & Byers.

- Ron Conway (1951, USA): Inversor Angel en Google, Ask Jeeves, PayPal, etc.

- Eric Schmidt (1955, USA): CEO Google, Alphabet Inc.

- Vinod Khosla (1955, India): Fundador de Sun Microsystems.

- Bill Gates (1955, USA): Fundador de Microsoft.

- Meg Whitman (1956, USA): CEO HP, Ex CEO eBay.

- Mark Hurd (1957, USA): Co-CEO Oracle Corp. Ex CEO de NCR Corp. y HP.

- Tim Cook (1960, USA): CEO Apple Inc.

- Reed Hastings (1960, USA): Fundador de Netflix.

- Brian Krzanich (1960, USA): CEO Intel.

- Safra Ada Catz (1961, Israel): Co-CEO Oracle Corp.

- Devin Wenig (1966, USA): Presidente y CEO de eBay.

- Peter Thiel (1967, USA): Co-Fundador de PayPal. Socio de The Founders Fund (VC).

- Reid Hoffman (1967, USA): Fundador de LinkedIn, Trabajo en Paypal, Inversor en Facebook,
Zynga.

- Sheryl Sandberg (1969, USA): COO Facebook.

- Marc Andreessen (1971, USA): Fundador de Netscape Communications Corp, co-creador de Mosaic, diseñador de SSL.

- Elon Musk (1971, Sudafrica): PayPal, Tesla Motors, SpaceX, SolarCity, Hyperloop y OpenAI.

- Larry Page (1973, USA): Co-Fundador de Google.

- Sergey Brin (1973, Rusia): Co-Fundador de Google.

- Marissa Mayer (1975, USA): CEO Yahoo.

- Mark Zuckerberg (1984, USA): Fundador de Facebook.

6. Principales Universidades en Computación y TI en Silicon Valley (por año de fundación)

- Santa Clara University (1851)

- San José State University (1871)

- Stanford University (1885)

- College of San Mateo (1922)

- California State University, East Bay (CSUEB) (1957)

- University of California, Santa Cruz (1965)

- De Anza College (1967)

- International Technological University (ITU) (1994)

- Silicon Valley University (SVU) (1997)

7. Principales Libros sobre Sillicon Valley (extraido de goodreads) (por año de publicación)

- Libro: Hackers: Heroes of the Computer Revolution
  Autor: Steven Levy
  Año: 1984

- Libro: Only the Paranoid Survive
  Autor: Andrew S. Grove
  Año: 1988

- Libro: Hard Drive: Bill Gates and the Making of the Microsoft Empire
  Autor: James Wallace
  Año: 1992

- Libro: The New New Thing: A Silicon Valley Story
  Autor: Michael Lewis
  Año: 1999

- Libro: Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age
  Autor: Michael A. Hiltzik
  Año: 1999

- Libro: Softwar: An Intimate Portrait of Larry Ellison and Oracle
  Autor: Matthew Symonds
  Año: 2003

- Libro: Hackers & Painters: Big Ideas from the Computer Age
  Autor: Paul Graham
  Año: 2004

- Libro: Revolution in The Valley: The Insanely Great Story of How the Mac Was Made
  Autor: Andy Hertzfeld
  Año: 2004

- Libro: Bill & Dave: How Hewlett and Packard Built the World's Greatest Company
  Autor: Michael S. Malone
  Año: 2007

- Libro: The Accidental Billionaires: The Founding of Facebook, a Tale of Sex, Money,
  Genius and Betrayal.
  Autor: Ben Mezrich
  Año: 2009

- Libro: An Engineer's Guide to Silicon Valley Startups
  Autor: Piaw Na
  Año: 2010

- Libro: The Facebook Effect: The Inside Story of the Company That is Connecting the World
  Autor: David Kirkpatrick
  Año: 2010

- Libro: In the Plex: How Google Thinks, Works, and Shapes Our Lives
  Autor: Steven Levy
  Año: 2011

- Libro: I, Steve: Steve Jobs In His Own Words
  Autor: George Beahm
  Año: 2011

- Libro: Steve Jobs
  Autor: Walter Isaacson
  Año: 2011

- Libro: The Circle
  Autor: Dave Eggers
  Año: 2013

- Libro: Hatching Twitter: A True Story of Money, Power, Friendship, and Betrayal
  Autor: Nick Bilton
  Año: 2013

- Libro: Fearless Genius: The Digital Revolution in Silicon Valley 1985-2000
  Autor: Doug Menuez
  Año: 2014

- Libro: How Google Works
  Autor: Eric Schmidt
  Año: 2014

- Libro: Chaos Monkeys: Obscene Fortune and Random Failure in Silicon Valley
  Autor: Antonio Garcia Martinez
  Año: 2016

- Libro: Zero to One: Notes on Startups, or How to Build the Future
  Autor: Peter Thiel
  Año: 2016

8. Videos de Entrevistas a Personajes de Silicon Valley

- Steve Jobs and Bill Gates Face Off



- Mark Zuckerberg at Startup School 2013



- Copy of In Tech We Trust? A Debate with Peter Thiel and Marc Andreessen


- Peter Thiel: being contrarian & right, AI, Elon, drug reform, overrated trends & wealth polarization



- Devin Wenig, CEO eBay | Full interview | Code Conference 2016


- Elon Musk | Full interview | Code Conference 2016


- Google's push to improve Nexus phones | Sundar Pichai, CEO Google | Code Conference 2016


- Jeff Bezos vs. Peter Thiel and Donald Trump | Jeff Bezos, CEO Amazon | Code Conference 2016


- Philanthropy can be innovative | Bill Gates and Melinda Gates | Code Conference 2016



lunes, 25 de julio de 2016

Artículo: Temas a Aprender en un Lenguaje de Programación

Temas a Aprender en un Lenguaje de Programación

1. Introducción

Un Lenguaje de Programación es el medio por el cual los programadores dan ordenes al computador y sin importar que tipo de lenguaje estén usando todos ellos sirven para crear aplicaciones. En este artículo quiero compartir mi opinión sobre que temas deben aprenderse al momento de elegir un Lenguaje de Programación.

He tratado de hacer una especie de Syllabus genérico para cualquier Lenguaje de Programación, por ejemplo los temas lo puedes ver en cualquier lenguaje del servidor como C# en .NET, PHP, Phyton, Ruby, C++, etc. Pero también la mayoría de temas se pueden ver en JavaScript.

Este breve artículo servirá para que tanto estudiantes y profesionales sepan los temas que son necesarios y los mas útiles que deben conocer, por lo que se ha divido en 3 partes con 4 capítulos cada una: Básica, Intermedia y Avanzada.

2. Temas o Tópicos a Aprender

Parte Básica

1. Estructuras de Datos
1.1. Simples: Numéricas, Cadenas, Lógicas, Fecha, etc.
1.2. Complejas: Arreglos, Listas, Pilas, Colas, Arboles, etc.
1.2. Objetos: Clases, Intefaces, Propiedades, Métodos, Eventos, etc.

2. Estructuras de Control de Flujo
2.1. Condicionales: if, switch, case, etc.
2.2. Repetitivas o de Bucle: for, while, do..while, etc.
2.3. Control de Errores: try..catch

3. Creando Interfaces de Usuario (IU)
3.1. Formularios
3.2. Controles de Entrada: TextBox, Radio, Check
3.3. Controles de Ejecución: Button, LinkButton
3.4. Controles de Imagen: Image, ImageButton
3.4. Controles de Listas: ListBox, ComboBox
3.5. Controles de Vistas: GridView, TreeView, ListView
3.6. Otros Controles: Calendarios, Banners, Visores, etc.

4. Manejo de Entrada y Salida
4.1. Información del Sistema: Directorios, Rutas y Archivos
4.2. Lectura y Escritura: Archivos Secuenciales y Aleatorios
4.3. Codificación de Datos: Codificar y Decodificar datos
4.4. Manejo de Expresiones Regulares

Parte Intermedia

5. Acceso a Base de Datos (Conectado)
5.1. Conectarse a una Base de Datos
5.2. Ejecutar Comandos SQL: Select, Insert, Update, Delete
5.3. Trabajar con Procedimentos Almacenados

6. Manejo de Datos (Desconectado)
6.1. Consultas: Filtros y Búsquedas
6.2. Ordenación: Ascendente y Descendente
6.3. Paginación: Por Filas y Por Columnas
6.4. Transferencia: Importación y Exportación

7. Presentación o Visualización de Datos
7.1. Vistas: Tablas, Cabecera Detalle, Jerárquicas y Tabla Cruzada
7.1. Reportes: Por Código y Por Herramientas
7.2. Gráficos: Por Código y Por Controles
7.3. Impresiones: Presentación Preliminar, Configurar Pagina, Imprimir

8. Pruebas de la Aplicación
8.1. Pruebas Unitarias: Funcionalidad
8.2. Pruebas de Rendimiento: Velocidad
8.3. Pruebas de Disponibilidad: Continuidad
8.4. Pruebas de Seguridad: Protección

Parte Avanzada

9. Programación de la Reusabilidad
9.1. Módulos o Librerías de Clases
9.2. Módulos o Librerías de Controles

10. Programación Asíncrona
10.1. Subprocesamiento: Threads y ThreadPool en una CPU
10.2. Programación Paralela: Tareas en Múltiples CPU

11. Programación de Redes y Distribuida
11.1. Sockets: TCP, UDP
11.2. Web: HTTP (Get, Post, Put, Delete)
11.3. Web Sockets: WS
11.4. Servicios: RPC, SOAP, REST (HTTP)
11.5. Correos: IMAP, POP3, SMTP
11.6. Mensajería: AMQP, MQTT, STOMP
11.7. Archivos: FTP
11.8. Señales: STUN, TURN, ICE, NAT

12. Criptografía o Cifrado de Datos
12.1. Cifrado Simétrico: AES, DES, RC2, Rijndael, Triple DES, etc.
12.2. Cifrado Asimétrico: DSA, ECDiffieHellman, ECDSA, RSA, etc.
12.3. Valores Hash: MD5, RIPEMD160, SHA1, SHA256, SHA512, etc.
12.4. Firmas Digitales y Tokens

3. Comentario Final

Parte Básica

Los Institutos y Universidades que enseñan como curso oficial o electivo en pre-grado un Lenguaje de Programación deberían cubrir la parte básica, pero pasan mucho tiempo en los 3 primeros temas y se olvidan del manejo de entrada y salida, sobre todo del manejo de archivos y después cuando los alumnos son profesionales y trabajan no pueden leer cualquier tipo de archivo, excepto el de Texto: TXT, XML, JSON, CSV, pero no un Binario (DOC, XLS, EXE, DLL, etc)  o uno Comprimido (XLSX, DOCX, PPTX, etc.)

También noto muchos problemas en los programadores en los temas de Codificación de Datos (Encoding), Decodificación de Datos (Decoding) y Búsqueda de Patrones de Texto (Expresiones Regulares). Con una buena base educativa no tendría porque haber ningún tipo de problemas al desarrollar una aplicación en cualquier lenguaje.

Parte Intermedia

La parte intermedia esta dirigida a los profesionales que trabajan desarrollando aplicaciones y necesitan conocer los temas de acceso a datos (conectado) y manejo de datos (desconectado), presentación de datos y pruebas. Aquí la falla está en que se da mucho énfasis a la programación conectada pero No se entiende que ésta es la causante de que en las empresas "Los Sistemas están Lentos" porque "La Red está Lenta" porque "las aplicaciones realizan muchas conexiones" (miles por día), por lo que es "Indispensable" saber el manejo "Desconectado" con los datos.

En cuanto a la presentación de datos la mayoría de programadores solo saben "Herramientas de Reportes", por ejemplo "Crystal Reports" o "Report Viewer" (Reporting Services) o para crear Gráficos usan "Controles", abren instancias de aplicaciones como Word y Excel. Todas estas técnicas descritas son ineficientes ya que consumen mucha memoria y son lentas, hay otras formas de hacer reportes "super rápidos", por ejemplo en .NET para Windows se usa PrintDocument y en Web solo basta con HTML y JavaScript.

En cuanto a las Pruebas, los instructores solo saben enseñar "Pruebas Unitarias" que es lo mínimo que debe pedirse de la aplicación: que cumpla con la funcionalidad pedida, pero hay temas más técnicos como son la Performance o Rendimiento, la Disponibilidad como la tolerancia a Fallas de Red y la Seguridad (privacidad de datos, ataques, robo de información, etc.) que No se toman en cuenta. Es por esto que a cada momento vemos en todas partes "Sistemas Lentos", "Sistemas Caídos por Falta de Red", "Ataques a Sitios Web", "Robo de Datos", etc.

Parte Avanzada

En esta última parte si que estamos peor (según mi experiencia de mas de 25 años como programador e instructor), ya que los 4 últimos temas es poco probable que se enseñe en una capacitación tradicional, excepto Web HTTP (REST) y Servicios SOAP (porque está de moda), pero temas como crear tu propia librería de clases y controles o tu propio módulo de clases y controles Nunca se ve, solo se les enseña a usar lo que ya está hecho sin  siquiera ser selectivo con lo que se usa (solo extraer lo necesario del código o control).

Otro problema de muchos programadores es que No saben el "ABC" de la programación asíncrona, muchos piensan que solo se puede implementar en la web con AJAX, jQuery o cualquier Framework popular, cuando en la web en el lado del cliente puede usarse XHR (nativo) y en el servidor Threads, ThreadPool, Delegados-CallBacks, Tasks, etc. Es mas importante que apliques asíncrono al servidor que al cliente porque la del cliente es para dar una mejor "Experiencia de Usuario" y la del servidor es para que "No se quede Colgado", y al final vas a dar la peor experiencia al usuario.

En cuanto al tema de la programación de redes o distribuida, la mayoría desconoce el poder de los Sockets y Web Sockets para hacer comunicación bidireccional en tiempo real y solo saben la peor (Servicios SOAP: Unidireccional). También es necesario aprender a manejar archivos con FTP, correos con SMTP, colas con STOMP, Señales con STUN, etc.

Finalmente, el tema de la Seguridad es muy importante y parte de esta es el cifrado de datos como claves, contenido, archivos, etc. Es necesario conocer los 4 tipos de tareas criptográficas mas comunes: cifrado simétrico y cifrado asimétrico (bidireccionales), valores hash (unidireccionales) y Firmas Digitales.

En General

En General, el Comentario Final es que si queremos mejorar nuestro nivel sea que somos estudiantes o profesionales debemos saber cuales son los temas mas importantes en nuestra formación, siento que en todos los niveles de la educación: pre-grado (para estudiantes) y especialización (para profesionales) los temas que se enseñan no son los mas importantes para el trabajo. Se da mucho énfasis en patrones y reusabilidad ("Construye Fácil") pero no en lo mas importante: en Producción que sea "Veloz", "Seguro" y "Siempre Disponible".

Mi aporte en estos últimos años ha sido cambiar esa mentalidad de "lo fácil" (reusabilidad) por lo "fácil mas lo eficiente" (performance y si se puede reusabilidad), aunque me hubiese gustado llegar a mas gente (aunque sea en mi país), es por eso, que a través de este Blog y mi Canal de YouTube trato de compensar este déficit.

Espero que con este artículo logre contribuir a que los centros de enseñanza de Lenguajes o Herramientas de Programación tomen en cuenta los temas que son necesarios enseñar para tener mejores profesionales que nunca tengan problemas al momento de trabajar o si los tienen que los resuelvan de la mejor manera y lo mas rápido posible.

miércoles, 13 de julio de 2016

Artículo - JavaScript Developer

JavaScript Developer

1. Introducción

JavaScript es un Lenguaje de Programación interpretado desarrollado por Brendan Eich en 1995 cuando trabajaba en Netscape. JavaScript es orientado a objetos, basado en prototipos, débilmente tipado y dinámico. La especificación de este lenguaje se denomina ECMAScript y es elaborada por ECMA International.

Actualmente es uno de los Lenguajes de Programación mas usados en el mundo, ya que sirve para crear aplicaciones web, tanto de lado del cliente (desde sus inicios) y también de lado del servidor (en la actualidad).

En los 20 años de vida que tiene JavaScript, en los 10 primeros años solo se usaba para validaciones y manejo de controles, pero a partir de la incorporación de AJAX (2005), la creación de librerías como jQuery (2006), la creación de JavaScript en el servidor con NodeJS (2009), la aparición de las nuevas APIs sobre todo de HTML5 y la nueva especificación del lenguaje ECMAScript6 (2012), ha originado que JavaScript tenga un crecimiento exponencial.

Muchos desarrolladores escribían la mayor parte del código en el servidor, ya que los Frameworks de ese lado tenían una gran cantidad de APIs o Librerías que permitían realizar cualquier tipo de tareas, desde acceso a datos hasta gráficos, operaciones con datos, manejo de archivos, etc. Es por eso que se usaba mucho código en PHP, Java o .NET, ysolo un mínimo de código en JavaScript para validar, manejar el DOM y mejorar el formato o estilo.

Actualmente, todo lo que podíamos hacer en el servidor, lo podemos hacer en el cliente con JavaScript, desde hacer llamadas asíncronas con XHR o AJAX hasta manipular los datos, crear gráficos (en 2D y en 3D), cifrar datos, enviar y recibir notificaciones en tiempo real, etc. Esto se puede hacer nativamente usando las APIs de JavaScript o usando una Librería o Framework que encapsule dicho trabajo.

Nota: Antes yo escribía 80% de código en el servidor y 20% en el cliente, pero desde hace unos años escribo 20% de código en el servidor y 80% en el cliente usando JavaScript puro. Estos porcentajes concuerdan con "El Problema de la Performance" que se da 80% en el cliente y 20% en el servidor.

Muchos programadores creen conocer JavaScript, pero en realidad no conocen ni el 10% de lo que tiene. El propósito de este artículo es contribuir a aumentar ese conocimiento, mostrando la Historia, las APIs, las Librerías, los Frameworks, las Herramientas y las fuentes donde pueden aprender más sobre este lenguaje, para cambiar su forma de programar y usar "La Web como Plataforma de Desarrollo" a través del Navegador (Browser) usando como lenguaje "JavaScript".

2. Cronología de JavaScript (20 años)

- 1995: En Mayo Brendan Eich crea Mocha en 10 días
- 1995: En Setiembre se crea LiveScript
- 1995: En Diciembre cambia de nombre a JavaScript
- 1996: Microsoft crea JScript
- 1996: DHTML
- 1997: ECMA-262 Ed1 (ES1)
- 1998: DOM Level 1
- 1999: ES3 (Base JavaScript actual)
- 1999: Microsoft crea XmlHttpRequest (Pre-AJAX)
- 2000: DOM Level 2
- 2001: Douglas Crockford crea JSON
- 2004: DOM Level 3
- 2005: AJAX
- 2008: ECMAScript 4 (ES4)
- 2009: ECMAScript 5 (ES5). JSON, Object.create
- 2012: ECMAScript 6 (ES6). Modulos, Proxys
- 2012: Navigation Timing
- 2012: HTML5 Web Messaging
- 2012: Web Workers
- 2012: WebSocket
- 2013: Web Storage
- 2013: Touch Events
- 2013: Geolocation API
- 2013: Performance Timeline
- 2013: Web Notifications
- 2013: File API
- 2013: Messaging API
- 2013: Web Telephony API
- 2013: MediaStream Image Capture
- 2013: WebRTC 1.0
- 2013: Web Audio API
- 2014: Progress Events
- 2014: Indexed Database
- 2014: Server Sent Events (SSE)
- 2014: Web Cryptography API
- 2014: Web NFC API
- 2014: XMLHttpRequest Level 1
- 2014: Push API
- 2014: Streams API
- 2014: Screen Orientation API
- 2014: Service Workers
- 2014: TCP and UDP Socket API
- 2014: URL
- 2014: Clipboard API and Events
- 2015: ECMA-262 (6th Edition). ECMAScript 2015 Language Specification

3. APIs de JavaScript

- Document Object Model (DOM)
  -) HTML: Document, Element, Event, HTML..., Node, NodeList, ParentNode, etc.
  -) XML: XMLDocument.
  -) SVG: Scalable Vector Graphics

- Gráficos
  -) Canvas: CanvasGradient, CanvasRenderingContext2D, HTMLCanvasElement, ImageData.
  -) SVG: SVGAnimate, SVGAnimated, SVGColor, SVGElement, SGVFont, SVGPath, SVGText.
  -) WebGL: WebGLBuffer, WebGLObject, WebGLRenderbuffer, WebGLRenderingContext, etc.

- Almacenamiento
  -) File API: Blob, File, FileList, FileReader, FileReaderSync, URL.
  -) IndexedDB: IDBCursor, IDBDataBase, IDBFactory, IDBIndex, IDBObjectStore, etc.
  -) Web Storage: Storage, StorageEvent, WindowLocalStorage, WindowSessionStorage.

- Conectividad
  -) Web Sockets: BroadcastChannel, CloseEvent, EventSource, PortCollection, WebSocket.
  -) Messaging: MessageChannel, MessageEvent, MessagePort.
  -) WebRTC: RTCPeerConnection, RTCIceServer, RTCIceCandidate, RTCDataChannel, etc.

- Acceso:
  -) Drag And Drop (D&D): DataTransfer, DataTransferItem, DataTransferItemList, DragEvent.
  -) FullScreen: Document (fullscreenElement, fullscreenEnabled), Element (requestFullscreen).

- Estilos
  -) CSS Object Model: CSS, CSSRule, CSSStyleSheet, MediaList, StyleSheet, etc.
  -) Selectors: Document (querySelector, querySelectorAll), DocumentFragment, Element.

- Multimedia
  -) Animation Timing: Window (cancelAnimationFrame, requestAnimationFrame).
  -) Media: AudioTrack, HTMLMediaElement, HTMLTrackElement, MediaController, VideoTrack.
  -) Pointer Lock: Document (exitPointerLock), Element (requestPointerLock), MouseEvent.
  -) Web Audio: AnalyserNode, AudioBuffer, AudioListener, AudioParam, DelayNode, GainNode.

- Performance
  -) Browser: History, ImageBitmap, Location, MimeType, Navigator, WindowBase64 (atob, btoa),
     WindowTimers (clearInterval, clearTimeout, setInterval, setTimeout), etc.
  -) Typed Arrays: ArrayBuffer, ArrayBufferView, DataView, Float..Array, Int..Array, Uint..Array.
  -) Web Workers: AbstractWorker, SharedWorker, Worker, WorkerLocation, WorkerNavigator, etc.

- Componentes Web
  -) Shadow DOM: CSSHostRule, CSSRule, Element (createShadowRoot), ShadowRoot, etc.
  -) Custom Elements: Element (customElements.define)
  -) HTML Imports: HTMLLinkElement (rel=import), Document (write, close).

- ECMAScript
  -) Tipos de Datos Primitivos: Boolean, Null, Undefined, Number, String, Symbol (ES6).
  -) Tipos Objetos: Array, Date, Error, Function, Global, JSON, Math, Object, RegExp.
  -) Colección de Claves (Objetos): Maps, Sets, WeakMaps, WeakSets.

- Seguridad Web (WebCryptography)
  -) Clases: Crypto, Algorithm, KeyAlgorithm, CryptoKey, SubtleCrypto, etc.
  -) Operaciones: encrypt, decrypt, sign, verify, deriveBits, wrapKey, unwrapKey,
     generateKey, importKey, exportKey, getLength.
  -) Algoritmos: RSASSA-PKCS1-v1_5, RSA-PSS, RSA-OAEP, ECDSA, ECDH, AES-CBC,
     HMAC, DH, SHA-1, SHA-256, SHA-384, SHA-512, CONCAT, HKDF-CTR, PBKDF2, etc.

- Comunicación Asíncrona con el Servidor:
  -) Cliente al Servidor: XmlHttpRequest (XHR)
  -) Servidor al Cliente: Server-Send Events (SSE)
  -) Bidireccional: Web Sockets

4. Cronología de Librerías y Frameworks de JavaScript (11 años)

- 2004: Dojo Toolkit (Alex Russell)
- 2005: Prototype JavaScript Framework (Sam Stephenson)
- 2005: Script.aculo.us (Thomas Fuchs)
- 2006: Yahoo UI Library (YUI)
- 2006: Google Web Toolkit (GWT)
- 2006: jQuery (John Resig)
- 2006: MooTools (Valerio Proietti)
- 2007: ExtJS (Jack Slocum)
- 2007: WaveMaker (Scott Miles)
- 2007: jQuery UI (Scott González, Adam Sontag, etc)
- 2008: Processing.js (John Resig)
- 2008: QUnit (John Resig)
- 2009: CofeeScript (Jeremy Ashkenas)
- 2009: Glow (BBC)
- 2009: Raphaël (Dmitry Baranovskiy)
- 2009: NodeJS (Ryan Dahl)
- 2010: BackboneJS (Jeremy Ashkenas)
- 2010: KnockoutJS (Steve Sanderson)
- 2010: AngularJS (Misko Hevery)
- 2010: Three.js (Ricardo Cabello)
- 2010: jQuery Mobile (jQuery Foundation)
- 2010: Jasmine (Pivotal Labs)
- 2011: Dart (Lars Bak, Kasper Lund)
- 2011: Ember.js (Yehuda Katz, Tom Dale)
- 2011: Modernizr (Paul Irish)
- 2011: D3.js (Bostock, Heer, Ogievetsky)
- 2011: Kendo UI (Telerik)
- 2011: Unit.js (Nicolas Tallefourtane)
- 2012: TypeScript (Anders Hejlsberg)
- 2012: Bootstrap (Mark Otto, Jacob Thornton)
- 2012: Enyo.js (Palm, HP)
- 2012: Meteor (Meteor Development Group)
- 2012: ExpressJS (TJ Holowaychuk)
- 2013: Polymer (Google)
- 2013: X-Tag (Mozilla)
- 2013: Webix (XB Software)
- 2013: React (Jordan Walke)
- 2013: Sails.js (Mike McNeil)
- 2013: Snap.svg (Adobe)
- 2014: Underscore.js (Jeremy Ashkenas)
- 2014: Socket.io (Guillermo Rauch)
- 2015: Reac Native (Tom Ochinno, Christopher Chedeau)
- 2015: Aurelia.io (Rob Eisenberg)

5. Herramientas de JavaScript

5.1. Herramientas de Calidad del Código (JavaScript Code Quality Tools)

1. JSLint
- Es la más antigua y fué creada por Douglas Crockford en el 2002

2. JSHint
- Team: Rick Waldron, Caitlin Potter, Mike Sherov, Mike Pennisi, y Luke Page

3. JSCS (JavaScript Code Style checker)
- Team: Marat Dulin, Oleg Gaidarenko, Mike Sherov, Joel Kemp, Alexej Yaroshevich, Henry Zhu

4. ESLint (Pluggable JavaScript Linter)
- Originalmente creada por Nicholas C. Zakas en el 2013
- Actualmente mantenida por jQuery Foundation
- Usuarios: Algolia, Disqus, 2GIS
- Requerimientos: Node.js or io.js
- Sistemas Operativos: Windows, Mac, Linux

5.2. Herramientas de Pruebas Unitarias (JavaScript Unit Testing Tools)

1. QUnit (JavaScript Unit Testing framework)
- Originalmente creada por Jhon Resign en el 2006 como parte de jQuery
- En el 2008 fue extraida de jQuery para ser independiente en el 2009
- Usos: jQuery, jQuery UI, jQuery Mobile

2. Unit.js (Unit testing framework for JavaScript)
- Creado por el Francés Nicolas Talle (Nicolab) en el 2014
- Requerimientos: Node.js y el Browser

3. Jasmine (Behavior-Driven JavaScript)
- Creada por Pivotal Labs en el 2010

4. Mocha (the fun, simple, flexible JavaScript test framework)
- Creada en el 2011 por la organización Mocha
- Requerimientos: Node.js y el Browser
- Usos: should.js, express.js, chai, better-assert, unexpected
- Usuarios: Sauce Labs, Yahoo
- Contribuidores: Christopher Hiller, Daniel St. Jules, ScottFreeCode, David Da Silva

6. Entrenamiento en JavaScript

6.1. Libros











6.2. Cursos Oficiales Microsoft Virtual Academy (MVA)











6.3. Tutoriales























6.4. Conferencias













6.5. Reuniones (Meetups)







6.6. En Vivo (Hangouts)



7. Comentario Final

En este artículo me propuse dar la mayor cantidad de información sobre JavaScript, ya que en muchos lugares todavía no se toma conciencia de la necesidad de trabajar lo mas desconectado posible y solo actualizar en tiempo real los datos cuando ocurran cambios, para lo cual es necesario conocer mas JavaScript.

Particularmente, en los últimos 3 años mi orientación de desarrollador, cambio radicalmente, hacia el lado del cliente usando JavaScript y priorizando la performance usando una arquitectura con pocos archivos y poco contenido lo cual tiene ventajas en velocidad incomparables.

Si bien es cierto, en la mayor parte del mundo se esta de acuerdo en que JavaScript es el número 1 por encima de Java, PHP, Phyton, Ruby, C#, C++, etc; donde no estoy de acuerdo es en el uso indiscriminado de Frameworks sobre todo de lado del cliente que "debilitan el rendimiento".

Los programadores tienen que entender que el Navegador (Browser) es un Framework con cientos de clases y métodos (APIs), las cuales detallamos en el tema 3 de este artículo: "APIs de JavaScript" y que no es necesario usar ninguna Librería ni Framework para hacer cualquier cosa (al final tanto las Librerías como los Frameworks usan dichas APIs).

Hay que invertir mas tiempo aprendiendo lo que nunca pasará de moda (lo nativo) y dejar de lado la moda (las Librerías y Frameworks, que salen por decenas en un año y en poco quedan obsoletas). De mi parte llevo enseñando mas de 3 años las APIs de JavaScript en cada curso, taller o capacitación que hago.

Lamentablemente, en muchas partes todavía se piensa que se debe hacer todo de lado del servidor y los que piensan lo contrario (hacerlo de lado del cliente) lo hacen usando Librerías o Frameworks, por tanto, mi arquitectura y mis técnicas de programación de lado del cliente con JavaScript son solo requeridas por un grupo reducido de seguidores, lo cual me apena mucho y me anima a dar un paso al costado, ya que el mercado laboral y el de entrenamiento es reducido (todos quieren lo estándar, nadie quiere cambiar 180 grados).

Si los programadores siguieran las técnicas usadas en mis capacitaciones, cursos o talleres verían la diferencia brutal de velocidad entre una pagina web clásica o moderna (MVC, SPA, etc.) con lo que nosotros hacemos en forma nativa con pocos archivos: un HTML, un CSS, un JavaScript y un Sprite.

Si les gusto no se olviden de dar Like y el que desea lo puede compartir en cualquier medio: Sitio Web, Google+, FaceBook, Twitter, solo mantener el nombre del creador. Los que están llevando el Taller de los Domingos no falten ya que es el último mes de mi último curso (aprovechen lo poco que queda).

miércoles, 9 de diciembre de 2015

Artículo - Pruebas de Performance

Pruebas de Performance

En este artículo veremos un caso práctico de pruebas del software: las pruebas de performance, que son las más necesarias en los sistemas web, debido al creciente incremento de usuarios y sobre todo de dispositivos que se pueden conectar a una aplicación web.

1. Criterios para Medir la Performance

Primero debemos entender que la medición de la performance de un sitio web se realiza a nivel de cada página, es decir, para medir la performance de todo el sitio web debemos medir la performance de cada página y luego hacer un promedio.

Entre las principales métricas para medir la performance de una página tenemos:
  • Tiempo de carga (Load Time)
  • Tiempo del primer byte recibido (First Byte)
  • Índice de velocidad (Speed Index)
  • Elementos del Modelo de Objetos del Documento (DOM Elements)
Por otra parte, estas métricas deben aplicarse en 2 momentos
  • La primera vez (First View)
  • Las demás veces (Repeat View)
Solo para recordar, hay que mencionar que los principales factores que afectan a la performance son:
  • Cantidad de solicitudes hechas por la página (Request)
  • Cantidad de datos enviados al cliente (Bytes)
Para obtener un buen puntaje debemos hacer la menor cantidad de solicitudes en cada página, es decir, usando pocos archivos CSS, JavaScript, Imágenes y Fuentes.

Además cada archivo debe tener la menor cantidad de datos, es decir, solo lo que se va a usar; en el caso de CSS las clases, en el caso de JavaScript las funciones y en el caso de las imágenes y las fuentes tienen que estar optimizadas.

2. Herramientas para Pruebas de Performance

Existen muchas herramientas para medir la performance, entre las más usadas en el mundo tenemos:

2.1. YSlow

Esta herramienta fue la primera en medir la performance y la primera versión fue creada por Steve Souders en Yahoo en el 2007, actualmente está disponible la versión 2.0 mantenida por Marcel Duran de Twitter.

YSlow es un complemento que se agrega al navegador (Browser) y está disponible para casi todos los navegadores (Firefox, Chrome, Safari, Opera, etc.) menos para Microsoft Internet Explorer.

URL: http://yslow.org/

Página Web de YSlow

Esta herramienta, identifica 34 criterios claves de los cuales actualmente usa 23 criterios para medir la performance de la página, los cuales se muestran en la siguiente figura.

Criterios para Medir Performance de YSlow V2.0

2.2. PageSpeed Insights

Esta herramienta desarrollada por Google en el 2013, inicialmente estaba disponible como una extensión para los navegadores, pero actualmente está disponible como una página web dentro del sitio de desarrolladores de Google.

Una de las ventajas de esta herramienta es que analiza la performance tanto para Desktop como para dispositivos móviles.

URL: https://developers.google.com/speed/pagespeed/insights/

Página Web de PageSpeed Insights

2.3. WebPageTest

Es una herramienta inicialmente desarrollada por AOL en el 2008 y actualmente mantenida por Google. 

Es una de las más usadas actualmente ya que muestra información completa de todas las métricas de performance vistas anteriormente.

URL: http://www.webpagetest.org/

Página Web de WebPageTest

3. Página de Prueba: Login del Sistema

Para las pruebas con las 3 herramientas hemos tomado la página de login de un sistema ubicado en la siguiente dirección.

URL: http://red.hteperu.com/test/Incentivos.Appweb/

Página Web de Prueba

Solo hay que resaltar que la página está en ASP.NET MVC y se compone de lo siguiente:
  • 1 archivo html para la página
  • 1 archivo de hoja de estilo: Login.css
  • 2 archivos de JavaScript: md3.js y Login.js
  • 2 archivos de fuentes: regular.woff y regular.woff2
Las pruebas se harán usando Google Chrome V46.0.2490.86 m (64 bits)

4. Pruebas de Performance usando YSlow

Después de descargar el complemento YSlow V2.0 abrir la herramienta y realizar los siguientes pasos:
  • Ir a la dirección URL: http://red.hteperu.com/test/Incentivos.Appweb/.
  • Clic al botón “Run Test” de la ficha “Home” similar a lo mostrado en la figura.
Ficha Inicio de YSlow V2.0

  • Automáticamente se irá a la ficha “Grade” similar a lo mostrado en la figura.
Ficha Grado de YSlow V2.0

  • En esta ficha se aprecia el puntaje obtenido por la página, en este caso “93 puntos” obteniendo el grado “A” que significa un buen resultado.
  • Para mejorar el puntaje necesitamos usar CDN (grado C), usar cabeceras de expiración (grado E), configurar Entity Tags (grado D).
  • Si deseamos ver el detalle por tipo de archivos seleccionamos la ficha “Components” y se mostrará algo similar a la siguiente figura.
Ficha Componentes de YSlow V2.0
  • En la figura notamos que aparece un mensaje de color rojo indicando que No se encuentra el archivo favicon (icono de la página web).
  • Si deseamos ver una estadística de archivos por tipos seleccionamos la ficha “Statistics” y se mostrará algo similar a la siguiente figura.
Ficha Estadística de YSlow V2.0

Finalmente, en esta ficha podemos darnos cuenta de que solo se está guardando en cache los archivos de hojas de estilos (css) y de JavaScript (js) pero no la página principal y el icono de inicio (ya que éste no existe).

En términos generales, diremos que hemos pasado la prueba de performance usando YSlow V2.0 de Yahoo.
5. Pruebas de Performance usando PageSpeed Insights

Para realizar las pruebas con esta herramienta realizar los siguientes pasos:
  • Ir a la dirección URL: 
https://developers.google.com/speed/pagespeed/insights/.
  • Ingresar la dirección de la página web con el login:
http://red.hteperu.com/test/Incentivos.Appweb/
  • Clic al botón “Analize” tal como se muestra en la siguiente figura.
Página principal de PageSpeed Insights
  • Automáticamente aparecerá los resultados de la ficha “Mobile” que tiene 2 partes: Velocidad y Experiencia de Usuario.
  • A continuación se muestra un gráfico con la sección de “Velocidad” de la ficha “Mobile”.

Sección Velocidad de la ficha Mobile de PageSpeed Insights

  • Aquí se aprecia que se ha fallado en 2 reglas y se ha pasado 8 reglas. Los 2 temas a mejorar son cargar asíncronamente el archivo CSS y el otro es usar cabeceras de expiración para guardar en cache los archivos JS y CSS.
  • A continuación se muestra un gráfico con la sección de “Experiencia de Usuario” de la ficha “Mobile”.
Sección Experiencia de Usuario de la ficha Mobile de PageSpeed Insights
  • En esta se aprecia que no hay ningún problema de experiencia de usuario si la página se ve en un dispositivo móvil.
  • Si cambiamos a la ficha “Desktop” ésta tiene solo la parte de Velocidad que es exactamente la misma que la de la ficha Mobile.
  • A continuación se muestra un gráfico con la sección de “Velocidad” de la ficha “Desktop”.
Sección Velocidad de la ficha Desktop de PageSpeed Insights
  • En términos generales, podemos decir que también hemos pasado la prueba de performance usando PageSpeed Insights de Google.
6. Pruebas de Performance usando WebPageTest

Para realizar las pruebas con esta herramienta realizar los siguientes pasos:
  • Ir a la dirección URL: 
http://www.webpagetest.org/.
  • Ingresar la dirección de la página web con el login:
http://red.hteperu.com/test/Incentivos.Appweb/
  • Clic al botón “Start Test” tal como se muestra en la siguiente figura.
Página principal de WebPageTest
  • Aparece un mensaje de probando (Testing) y luego se muestra el resultado del test similar al de la siguiente figura.
Página de Resultado de la Prueba en WebPageTest
  • Nuevamente apreciamos que la página web está casi bien excepto que debe usar Cache para archivos JS y CSS (F) y usar CDN (X).
  • Podemos analizar la primera ficha “Summary” que muestra un resumen con una tabla con los tiempos de carga y un par de gráficos con la primera vista y la vista repetida, similar a la siguiente figura.
Ficha Resumen del Resultado de WebPageTest
  • La segunda ficha “Details” muestra mayor detalle de los tiempos de carga, un gráfico de cascada, un gráfico de conexiones y una tabla con las solicitudes realizadas por la página.
  • El gráfico de cascada o “Waterfall View” muestra los tiempos de carga por cada recurso de la página, similar a la siguiente figura.
 Vista Cascada de la Ficha Detalle del Resultado de WebPageTest
  • El gráfico de conexión o “Connection View” muestra los tiempos de carga por conexiones realizadas al servidor, similar a la siguiente figura.
Vista Conexión de la Ficha Detalle del Resultado de WebPageTest
  • Finalmente en la sección de Detalles la tabla “Request Details” muestra los detalles de las solicitudes realizadas por la página, similar a la siguiente figura.
Detalles de Solicitud de la Ficha Detalle del Resultado de WebPageTest
  • Las filas pintadas de color rojo indican peligro, en este caso, el archivo de fuentes woff2 no ha sido registrado en el servidor como extensión conocida (MIME) y el otro problema es que la página no cuenta con un icono de inicio.
  • La tercera ficha “Performance Review” permite mostrar una revisión de las métricas de performance, para lo cual presenta una tabla con la lista de verificación a mejorar, el detalle y un glosario.
Lista de verificación de la Ficha Revisión del Resultado de WebPageTest
  • En el “CheckList” se aprecia claramente los temas que se pueden mejorar (color rojo), el archivo de fuente woff2 y el archivo de icono, además de usar caché para contenido estático (CSS, JS) y usar un servidor CDN.
Detalles de la Ficha Revisión del Resultado de WebPageTest

Glosario de la Ficha Revisión del Resultado de WebPageTest
  • La cuarta ficha “Content Breakdown” permite desglosar el contenido por tipo de recurso, mostrando 4 gráficos: por tipo MIME y por Conexión, tanto para la primera vista como para las vistas repetidas.
Gráfico por Tipo MIME (Primera Vista) de la Ficha Desglosar Contenido del Resultado de WebPageTest

Gráfico por Conexión (Primera Vista) de la Ficha Desglosar Contenido del Resultado de WebPageTest

Gráfico por Tipo MIME (Vista Repetida) de la Ficha Desglosar Contenido del Resultado de WebPageTest

Gráfico por Conexión (Vista Repetida) de la Ficha Desglosar Contenido del Resultado de WebPageTest
  • La quinta ficha “Domains” muestra 2 gráficos de desglose de contenido pero por dominio, tanto para la primera vista como para las vistas repetidas.
  • Solo hay que mencionar que No es necesario tenar varios Dominios (incluyendo CDN) cuando el número de archivos es poco, por ejemplo en nuestro caso, la página de login tiene solo 6 archivos.
  • A continuación se muestra los gráficos de la ficha “Domains” conteniendo el desglose de contenidos para la primera vista y para las vistas repetidas.
Gráfico de desglose de contenido (Primera Vista) de la Ficha Dominio del Resultado de WebPageTest
Gráfico de desglose de contenido (Vista Repetida) de la Ficha Dominio del Resultado de WebPageTest

  • Finalmente, revisaremos la sexta y última ficha llamada “Screen Shot” que muestra 2 gráficos con las pantallas de la página totalmente cargada y otra con el Documento Completado, además también los mensajes de consola del Log.
  • A continuación se muestra los gráficos de la ficha “Screen Shot” y los mensajes del Log.
Gráfico de la Pantalla Totalmente Cargada de la Ficha Captura de Pantalla del Resultado de WebPageTest
Gráfico de la Pantalla con Documento Completado de la Ficha Captura de Pantalla del Resultado de WebPageTest
Gráfico de Log de la Ficha Captura de Pantalla del Resultado de WebPageTest

  • En términos generales, podemos decir que también hemos pasado la prueba de performance usando WebPageTest de Google.
Finalmente, si hacemos caso de las sugerencias de estas 3 herramientas de performance nuestro sitio será muy rápido.

Descarga del documento completo
Pruebas_Performance

lunes, 7 de septiembre de 2015

Artículos - Buenas Prácticas de Performance en Sitios Web

Buenas Prácticas de Performance en Sitios Web

Uno de los principales atributos de un sitio web es que tenga un Alto Rendimiento, es decir, una buena Performance. En esta sección veremos todo lo necesario para mejorar el rendimiento de nuestros sitios web.


1.   Factores para Medir la Performance de una Aplicación
Los 2 factores más importantes para medir la performance son:
·         Tiempo de Procesamiento, el cual debe ser el menor posible
·         Consumo de Memoria, el cual también debe ser el menor posible

2.   Componentes de un Sitio Web
Los componentes de un Sitio Web los podemos dividir en 2 grandes grupos:
Front-End
Representa el inicio del procesamiento, sobre el cual interactúa el usuario y envía las órdenes al Back-End.
En un entorno web éste se compone básicamente por el Navegador (Browser), el cual procesa los siguientes elementos:
·         HTML, son las etiquetas que especifican lo que hay que Pintar en el Navegador.
·         JavaScript, son Secuencias de Comandos que debe ejecutar el Motor de Scripts.
·         Hojas de Estilos (CSS), son los formatos que se aplicarán a los elementos HTML.
·         Imágenes, son gráficos que debe mostrar el navegador, etc.

Componentes del Front-End de un Sitio Web
Todos estos elementos se encuentran definidos dentro de la página y deben descargarse desde el Servidor Web hacia el Cliente Web (navegador).
Back-End
Representa el final del procesamiento y se encarga de procesar las llamadas del Front-End y devolver resultados.
En un entorno web éste se compone de los Servidores entre los cuales tenemos:
·         Servidor Web, donde se aloja la aplicación web, por ejemplo, el Internet Information Services (IIS) de Microsoft.
·         Servidor de Datos, donde se aloja la base de datos, por ejemplo, el SQL Server de Microsoft.
·         Servidor de Aplicaciones, donde se aloja los Componentes Reusables, por ejemplo, el IIS con Servicios WCF, un Host WCF con Servicios, un Host .NET Remoting con Librerías Remotas, etc.
Componentes del Back-End de un Sitio Web

3.   El problema de la Performance en los Sitios Web
Hace varios años un equipo de investigadores de Yahoo, encabezados por Steve Souders, investigó el problema de la performance, que es: “Cuales son los factores que causan que un Sitio Web sea lento”.
La conclusión a la que llegaron fue que entre el 80 y 85 % de la velocidad de carga de una página está asociada al Front-End y solo del 15% al 20% de problemas lo causa el Back-End.
En síntesis, para dar mayor velocidad a nuestras aplicaciones, hay que optimizar sobre todo la página en el lado del cliente, es decir, HTML, JavaScript, CSS, Imágenes, etc, lo cual se trata con mayor detalle a continuación.


Estadística del Problema de la Performance

4.   Las 14 Reglas de Performance de Steve Souders
En el 2007 Steve Souders arquitecto principal de Yahoo escribió el Libro: “High Performance Web Sites”, en el cual resume en 14 reglas los criterios más importantes para la velocidad de un Sitio Web, además creó una herramienta llamada YSlow que ayuda a medir la performance, que junto a PageSpeed de Google son las herramientas más usadas para este fín.
Las 14 reglas de Steve Souders para que un sitio web tenga un alto rendimiento son:
·         Regla 1: Hacer pocas solicitudes HTTP
·         Regla 2: Usar una Red de Entrega de Contenidos (CDN)
·         Regla 3: Añadir una Cabecera HTTP con el Tiempo de Expiración
·         Regla 4: Comprimir Componentes usando GZIP
·         Regla 5: Ubicar la Definición de Hojas de Estilos al inicio de la página
·         Regla 6: Ubicar la Definición de JavaScripts al final de la página
·         Regla 7: Evitar usar Expresiones CSS
·         Regla 8: Usar JavaScript y CSS externos (archivos)
·         Regla 9: Reducir Búsquedas en Sistema de Nombres de Dominios (DNS)
·         Regla 10: Minificar o Reducir JavaScript y CSS
·         Regla 11: Evitar Redirecciones
·         Regla 12: Remover Scripts duplicados
·         Regla 13: Configurar ETags
·         Regla 14: Guardar en Cache Ajax

5.   Otras 14 Consideraciones de Performance de Steve Souders
En el 2009 Steve Souders escribe otro Libro titulado: “Even Faster Web Sites”, en colaboración con otros especialistas, como:
·         Dion Almaer y Ben Galbraith, líderes de la comunidad Ajax (Mozilla).
·         Douglas Crockford, creador de JSON (Yahoo).
·         Tony Gentilcore, creador de Fasterfox (Google).
·         Dylan Schiemann, co-creador de Dojo Toolkit (SitePen).
·         Stoyan Stefanov, co-creador de YSlow 2.0 y Smush.it (Yahoo).
·         Nicole Sullivan, experta en CSS, co-creadora de Smush.it (W3C)
·         Nicholas C. Zakas, co-creador de YUI Library (Yahoo).
Estas 14 consideraciones para que un sitio web sea siempre rápido son:
·         Consideración 1: Optimizar Ajax
·         Consideración 2: Crear Aplicaciones Web Adaptativas
·         Consideración 3: Dividir la Carga Inicial de la Página
·         Consideración 4: Cargar Scripts sin bloquear el Navegador
·         Consideración 5: Unir Scripts Asíncronos
·         Consideración 6: Posicionamiento de Scripts en línea
·         Consideración 7: Optimizar JavaScript
·         Consideración 8: Escalado con Comet
·         Consideración 9: Aumentando GZIP
·         Consideración 10: Optimizando Imágenes
·         Consideración 11: Fragmentando Dominios Dominantes
·         Consideración 12: Nivelar desde el inicio el Documento
·         Consideración 13: Usar escasamente los iFrames
·         Consideración 14: Simplificar los Selectores CSS

6.   Principales Reglas de Performance en Sitios Web

·         Regla 1: Hacer la menor cantidad de solicitudes (HTTP Request)
Para cumplir con esta regla se deberá bajar la menor cantidad de archivos del servidor al cliente, por lo que se debe tener en cuenta lo siguiente:
Ø  Tratar de enviar solo uno o dos archivos de JavaScript. De preferencia debe ser un solo archivo conteniendo solo las funciones usadas en dicha página. Sin son 2 archivos JS uno será genérico (compartido para varias páginas) y otro específico (solo para dicha página).
Ø  Tratar de enviar solo uno o dos archivos de Hojas de Estilos. De preferencia debe ser un solo archivo conteniendo solo los estilos usados en dicha página. Sin son 2 archivos CSS uno será genérico (compartido para varias páginas) y otro específico (solo para dicha página).
Ø  Tratar de Reducir el número de imágenes enviadas al cliente usando Sprites o si las imágenes son pequeñas enviando un flujo serializado como Base64 String.
Comentarios
Actualmente, la mayoría de Sitios Web No cumplen con la regla más importante de la performance, por las siguientes razones:
Ø  Uso de varios archivos de JavaScripts de Frameworks como jQuery, jQueryUI, PlugIns, etc; la mayoría de veces solo por usar unas cuantas características (funciones) de cada uno en la página, innecesariamente se bajan todos los archivos con todas las funciones.
Ø  Uso de varios archivos de Hojas de Estilos de Frameworks de Diseño Web Adaptativo (Responsive Web Design) como Bootstrap, jQuery Mobile, etc; la mayoría de veces solo por usar unas cuantas características (estilos) de cada uno en la página, innecesariamente se bajan todos los archivos con todos los estilos.
Ø  Uso exagerado de archivos de imágenes para mejorar la apariencia de la página, sin importar que por cada archivo mostrado se tenga que hacer un viaje desde el cliente hacia el servidor para traerla y mostrarla.
Ø  El hacer Bundling (Fusión de Archivos) para los JS y CSS No es la mejor solución, ya que si bien es cierto se envía un solo archivo al cliente se incumple la segunda regla ya que se envía mucho contenido.

·         Regla 2: Enviar la menor cantidad de bytes al cliente
Esta segunda regla requiere enviar la menor cantidad de datos del servidor al cliente, incluyendo: HTML, JavaScript, CSS, Imágenes, etc; para lo cual debemos tener en cuenta lo siguiente:
Ø  Solo incluir las funciones de JavaScript que se van a usar en la página.
Ø  Solo incluir los estilos que se van a usar en la página.
Ø  Una vez seleccionado solo las funciones necesarias, minificar el archivo JS.
Ø  Una vez seleccionado solo los estilos necesarios, minificar el archivo CSS.
Ø  Minificar el HTML de la página que viene del servidor, si se usa controles de lado del servidor se deberá crear un Modulo HTTP que intercepte el contenido y minifique el HTML.
Ø  Optimizar las imágenes antes de enviarlas al cliente, reduciendo su tamaño y escogiendo un formato comprimido que no pierda la calidad, por ejemplo el formato png o web-p.
Comentarios
Actualmente, la mayoría de Sitios Web tampoco cumplen con la segunda regla más importante de la performance, por las siguientes razones:
Ø  Cuando usan archivos de JavaScript de terceros, no seleccionan solo las funciones que necesitan en la página y las copian a su único archivo JS, sino que se descargan todos los archivos con todas las funciones tal cual venga en el Framework JavaScript que están usando.
Ø  Cuando usan archivos de hojas de estilos de terceros, no seleccionan solo los estilos que necesitan en la página y las copian a su único archivo CSS, sino que se descargan todos los archivos con todos los estilos tal cual venga en el Framework Responsive Web Design que están usando.
Ø  Minificar los archivos JS con todas las funciones que vienen en los Frameworks de JavaScript, las cuales en su mayoría no se usan, es una solución incompleta, lo mejor es minificar solo las funciones que se usan y no enviar en vano tanto contenido.
Ø  Minificar los archivos CSS con todos los estilos que vienen en los Frameworks Responsive, los cuales en su mayoría no se usan, es una solución incompleta, lo mejor es minificar solo los estilos que se usan y no enviar en vano tanto contenido.
Ø  Muchos desarrolladores usan Controles de lado del Servidor que generan demasiado HTML, mejor sería enviar solo los datos necesarios y pintarlos en el cliente. Pero cuidado, no usar HTML, XML ni JSON, si queremos reducir al máximo el ancho de banda solo debemos enviar los datos sin metadata, por ejemplo, separados por un caracter, inclusive se pueden enviar imágenes como Base64String.

·         Regla 3: Hacer Llamadas Asíncronas Ligeras
Es muy importante mantener siempre la disponibilidad de la aplicación, es decir, por ejemplo, que el usuario siempre pueda trabajar con la interface de usuario. Para esto podemos usar la programación asíncrona, en el caso de las llamadas desde el cliente al servidor generalmente se usa Ajax, para lo cual debemos tener en cuenta lo siguiente:
Ø  Usar XMlHttpRequest (XHR) para hacer llamadas asíncronas en forma nativa, ya que es un estándar de la W3C que actualmente es soportado por todos los navegadores. Los que usan jQuery Ajax, Microsoft Ajax, Ajax Control Toolkit, etc, están usando una librería que internamente usa XHR. Por ejemplo, los métodos de jQuery: $.get, $.post, $.json y $.ajax son llamadas a los métodos open y send de XHR.
Ø  Enviar y recibir datos como cadenas (Text) al hacer llamadas asíncronas, ya que solo ocupa un 7% de todo el HTML (100%), mientras las vistas parciales con HTML son el 50% aproximadamente y si se usa JSON sería el 25% aproximadamente. Es decir, creando un Serializador en el Servidor (código C# en .NET) se puede convertir objetos a cadenas y reducir el ancho de banda en casi un 93%, logrando mayor velocidad de carga de la pagina, aunque tengamos que pintar los controles HTML por JavaScript.
Ø  No escribir código en el inicio de la página, dejarlo en un método que se llame en forma asíncrona, debido a que la primera vez siempre se demora la pagina en cargar y mas el código a ejecutar seria más lento, en cambio, si enviamos la pagina sin ejecutar ningún código al inicio, dejamos que cargue en el navegador y recién hacemos la llamada en forma asíncrona (segundo plano) usando XHR y devolviendo cadenas con los datos que se pintaran como HTML usando JavaScript.
Comentarios
Esta tercera regla también es ignorada por que en muchos casos se hace lo siguiente:
Ø  Se usa jQuery como librería de JavaScript para hacer operaciones asíncronas. En realidad, no fuera malo si solo se seleccionara los métodos que se van a usar, pero casi todos no lo hacen y se trabaja con el archivo JS completo, es por eso, que mejor sería usar directamente una función que use XmlHttpRequest.
Ø  Actualmente, en ASP.NET MVC, la mayoría para trabajar en forma asíncrona usa vistas parciales que envían HTML o jQuery que envía JSON (con metadata) el cual es pintado en el cliente. Esta segunda forma es mejor que la primera, pero la más óptima es que se envíe solo los datos (sin metadata) y se pinte en el cliente.
Ø  Siempre se implementa Ajax en el regreso de la pagina (PostBack), por ejemplo, al dar clic a un botón de consulta o al grabar; pero es indispensable que también se haga en el inicio, ya que es aquí donde se demora más y se necesita que el usuario vea rápido la pagina web y no se quede en blanco el navegador.

·         Regla 4: Optimizar las operaciones con Bases de Datos
Esta regla implica trabajar en forma desconectada la explotación de datos y en forma conectada por lotes la actualización de datos, para mayor detalle seguir las siguientes directivas:
Ø  Las operaciones con datos como búsquedas o filtros, paginación, ordenación, exportación de datos a texto, Excel, etc, se pueden realizar solo en el cliente usando JavaScript, en vez de estar yendo al servidor para realizar tareas con datos que muchas veces No cambian constantemente. Por ejemplo, el ubigeo, al seleccionar el Departamento, filtrar las Provincias y al seleccionar la Provincia filtrar los Distritos; muchos se van hasta el Servidor de Base de Datos, otros hasta el Servidor Web, cuando fácilmente podría hacerse en el cliente.
Ø  Las operaciones de actualización de datos, como inserción, actualización y eliminación generalmente se hacen en forma conectada, pero de preferencia debe hacerse por lotes, es decir no por cada registro sino por un grupo de registros, por ejemplo los mostrados en una página.
Ø  Si hay que insertar o actualizar muchos registros, por ejemplo más de 100, es preferible realizar copias masivas si el origen de datos es SQL Server u Oracle Server, para lo cual se almacena los datos en una tabla y se envía con la clase BulkCopy de ADO.NET. Otra alternativa sería enviar una cadena separada por caracteres especiales y tener un Procedimiento Almacenado que las separe y las inserte o actualice en su tabla destino.
Comentarios
Esta cuarta regla también no se cumple por las siguientes razones:
Ø  La mayor parte de las consultas a todo tipo de datos, desde el sexo, estado civil, ubigeo, tipo de documentos comerciales, empleados, clientes, proveedores, etc.; se realizan en forma conectada, siendo para la mayor parte de casos innecesario ya que los datos no varían constantemente. Algunos guardan los datos en variables de Sesión en el Servidor Web, a veces en un TempData en MVC para no ir hasta la BD, pero otros, si van a consultar a la Base de Datos creando conexiones constantemente y saturando el ancho de banda de la red.
Ø  En el caso de las actualizaciones, la mayoría trabaja en forma individual, es decir, realiza los cambios en cada registro, en vez de hacerlo por lotes o para un grupo de registros consumiendo una sola conexión a la base de datos, sobre todo si es gran cantidad de registros que se quiere actualizar o insertar.

7.   Arquitectura de Desarrollo Web de Bajo Rendimiento (ADWBR)
Una Arquitectura de Desarrollo Web que produce un Bajo Rendimiento (Low Performance) es aquella que tiene las siguientes características:
·         Está Orientada al momento del Desarrollo o a facilitar la Construcción, por lo que usa intensivamente Librerías o Frameworks de terceros.
·         Se piensa que favorece al Desarrollador ya que al usar bloques de código pre-construido (Frameworks) el tiempo de desarrollo es menor que si se hace todo desde cero.
·         Cada página descarga muchos archivos en el cliente, porque usa muchas librerías de JavaScript, muchos archivos de CSS y muchas imágenes que se bajan de uno en uno o de dos en dos, dependiendo del navegador que se use.
·         Se descarga mucho contenido, por ejemplo todo el HTML con los datos a presentar, todas las funciones JavaScript se usen o no y todos los estilos se usen o no. Eso ocurre por usar Frameworks de terceros y no ser selectivo, hay cosas que no se usan pero todo viaja.
·         Usan llamadas asíncronas pesadas, ya que envían muchos datos de ida y de vuelta, algunos usan XML como formato de transporte y otros reducen el ancho de banda usando JSON, pero igual se puede mejorar mas.
·         Hacen operaciones No óptimas con Bases de Datos, ya que todo se hace en forma conectada usando Frameworks pesados como Entity Framework, cuando trabajan en forma desconectada usan DataSet y DataTables, y cuando actualizan gran cantidad de registros lo hacen en forma individual ejecutando muchos comandos.
Componentes de una Arquitectura de Desarrollo Web de Bajo Rendimiento

8.   Arquitectura de Desarrollo Web de Alto Rendimiento (ADWAR)
Una Arquitectura de Desarrollo Web que produce un Alto Rendimiento (High Performance) es aquella que tiene las siguientes características:
·         Está Orientada al momento del Despliegue o a facilitar la Ejecución, por lo que se hace todo desde cero y nativo.
·         Favorece al usuario final, ya que la aplicación web será muy rápida, pero también puede favorecer al desarrollador ya que no habrá problemas de soporte post producción.
·         Cada página descarga pocos archivos en el cliente, solo un HTML, un JavaScript, un CSS, y las Imágenes se envían en un solo Paquete o como un archivo Sprite.
·         Se descarga poco contenido, por ejemplo solo viaja los datos como cadenas sin HTML y por JavaScript se crea el HTML como cadena y se pinta una vez en el DOM, el archivo JavaScript solo tiene las funciones que se van a usar en la pagina, el archivo CSS solo los estilos usados por esa página y las Imágenes están optimizadas (comprimidas).
·         Usan llamadas asíncronas ligeras mediante XmlHttpRequest (XHR), enviando los datos como cadenas tanto en la ida como en la vuelta, esto permite ahorrar en más de 90% el ancho de banda logrando mayor velocidad.
·         Hacen operaciones óptimas con Bases de Datos, ya que se usa ADO.NET para el acceso a datos, las consultas se trabajan en forma desconectada con Listas de Objetos en el Servidor Web y en el Cliente con Matrices en JavaScript. Las actualizaciones se hacen por lotes y para gran cantidad de registros se usa BulkCopy o Cadenas en el Procedimiento Almacenado.
Componentes de una Arquitectura de Desarrollo Web de Alto Rendimiento

Comentario Final

Se que muchos no compartiran algunas ideas de este artículo, ya que esta muy arraigado los estándares de reusabilidad que son diferentes a los de performance que es lo que yo propongo, y el cual en los últimos meses me he encargado de difundir, Tengo una nueva arquitectura que estoy trabajando basada en la Performance.

Los interesados en conocer la parte práctica y la comparación de resultados entre la arquitectura tradicional y la arquitectura que propongo pueden asistir este Sabado 12 de Setiembre de 2:00 pm a 2:50 pm en el CEPS de la UNI, del cual dejo la relación de charlas: