Colofón
Escrito por Camilo Castro y colaboradores[1]. Para Ninjas.cl[2] y Elixir Chile.
Esta obra está bajo una Licencia Creative Commons Atribución-No-Comercial-Compartir-Igual 4.0 Internacional[3]
1. Introducción
El siguiente documento da una pequeña pincelada sobre los conceptos necesarios para ser un desarrollador "Full-Stack". Una persona capaz de entender los distintos componentes que engloban un producto de software, principalmente en el área Web y Móvil.
Se comienza con la introducción a la historia de la tecnología, para luego ir al estado del ecosistema laboral actual, para continuar con una descripción de distintas tecnologías utilizadas en proyectos web y móviles. Finalmente termina con una descripción sobre el ecosistema de aplicaciones móviles.
Es una información muy útil para las personas que están recién comenzando dentro del rubro y también para personas experimentadas que deseen repasar ciertos conceptos.
2. Historia de la World Wide Web y Aplicaciones Móviles
En el siguiente capítulo detallaremos los inicios de la comunicación a distancia y las diferentes tecnologías utizadas hasta la actualidad.
2.1. Mensajes con Banderas
El Código Internacional de Señales de la OMI (Organización Marítima Internacional), esta basado en banderas destinado a transmitir mensajes, ya sea entre dos o más barcos, o entre un barco y la tierra o el puerto, en el cual cada letra o grupo de letras, representadas por banderas, tiene un significado particular. Es el código adoptado internacionalmente.
Desde que existe la comunicación por radio, el uso de las banderas de señales para transmitir mensajes ha disminuido notablemente. Sin embargo, se siguen utilizando de forma generalizada las banderas individuales o en combinaciones de dos, para señalizar un aviso determinado.
2.2. Mensajes con señales semáforo
El sistema de "señales semáforo", está basado en dos banderas iguales sostenidas una en cada mano del operador, formando distintas posiciones con respecto al cuerpo, era muy utilizado para comunicación diurna antes de la comunicación por radio, hoy en desuso, es solamente una opción de emergencia.
Este es un código de deletreo de mensajes, para el cual se utilizan dos banderas Oscar. Durante la noche, la comunicación de emergencia se realiza con luces por medio de código Morse.
2.3. Código Morse y Telégrafos
El artista estadounidense Samuel F. B. Morse, el físico estadounidense Joseph Henry, y el ingeniero mecánico Alfred Vail desarrollaron un sistema de telégrafo eléctrico. Necesitaba un método para transmitir el lenguaje natural utilizando solo pulsos eléctricos y el silencio entre ellos. Alrededor de 1837, Morse, por lo tanto, desarrolló un precursor temprano del código Morse Internacional moderno).
2.4. El Teléfono
El teléfono es un dispositivo de telecomunicación creado para transmitir señales acústicas a distancia por medio de señales eléctricas. Fue inventado por el italiano Antonio Meucci, quien en 1854 construyó su primer prototipo.
2.5. La Radio
En 1873, el físico escocés James Clerk Maxwell formuló la teoría de las ondas electromagnéticas, que son la base de la radio. En 1887, el físico alemán Heinrich Hertz confirmó las teorías de Maxwell, descubriendo la forma de producir y detectar ondas electromagnéticas, y en 1894 el serbio Nikola Tesla hizo su primera demostración en público donde transmitió en radio. Al poco tiempo, en 1895, el italiano Guillermo Marconi construyó el primer sistema de radio, logrando en 1901 enviar señales a la otra orilla del Atlántico, a través de 3360 km de océano; pero como lo hizo con patentes de Tesla se le atribuye el trabajo a este último.
2.6. Los Teletipos (Télex)
La red télex es una red de teletipos conmutada de cliente a cliente similar a una red telefónica, que utiliza circuitos de conexión de grado telégrafo para mensajes de texto bidireccionales. El télex fue un método importante para enviar mensajes escritos electrónicamente entre empresas durante el período posterior a la Segunda Guerra Mundial. Su uso disminuyó a medida que la máquina de fax creció en popularidad en la década de 1980.
2.7. Televisión por Cable
CATV es el servicio que ofrece transferencia de imágenes de televisión a los domicilios de los abonados. Existen redes de televisión por cable desde los años 1940. La primera red de cable fue montada en los Estados Unidos por un técnico en Oregón. La red contaba con un sistema de antenas, amplificadores y mezcladores de señal, y la señal era enviada por cables a sus vecinos, haciendo así posible que todos vieran televisión sin necesidad de antenas. Actualmente está extendido por todo el mundo.
2.8. Telefonía Celular
Martin Cooper fue el pionero en esta tecnología. A él se le considera «el padre de la telefonía móvil», al introducir el primer radio-teléfono en 1973, en Estados Unidos, mientras trabajaba para Motorola.
En 1983 Motorola lanzó el primer teléfono móvil del mercado: el Motorola DynaTAC 8000x. Su precio era de $3.995
dólares ($10.869
en 2023).
2.9. Los precursores de Internet
2.9.1. Arpanet (Red Telefónica)
ARPANET fue una red de computadoras creada por encargo del Departamento de Defensa de los Estados Unidos (DOD) para utilizarla como medio de comunicación entre las diferentes instituciones académicas y estatales. El primer nodo se creó en la Universidad de California en Los Ángeles (UCLA) y fue la espina dorsal de Internet hasta 1990, tras finalizar la transición al modelo de protocolos TCP/IP, iniciada en 1983.
2.9.2. Cybersyn/Synco (Red Télex)
El proyecto Synco o proyecto Cybersyn fue el intento chileno de planificación económica controlada en tiempo real, desarrollado en los años del gobierno de Salvador Allende, entre 1971 y 1973. En esencia, se trataba de una red de máquinas de teletipo que comunicaba a las fábricas con un único centro de cómputo en Santiago, donde se controlaba a las máquinas empleando los principios de la cibernética. El principal arquitecto del sistema fue el científico británico Stafford Beer.
2.9.3. Nabu (Red Cable)
NABU (Natural Access to Bi-directional Utilities) (Acceso natural a servicios públicos bidireccionales)
En 1982, se lanzó una computadora personal para el hogar a los consumidores para conectar a familias y empresas en una red mundial.
Fundada en Ottawa, Canadá, en 1982, las familias y las escuelas usaban módems de televisión por cable para conectar las PC de NABU a una red nacional. Además de las capacidades de PC estándar, la computadora NABU podría descargar software y contenido de información a través de la alimentación por cable. Las aplicaciones incluían juegos, lenguajes de programación y noticias.
2.10. Primeras Aplicaciones de Red
2.10.1. Email
El correo electrónico --también llamado simplemente correo-- (en inglés: electronic mail, normalmente abreviado e-mail o email) es un servicio de red que permite a los usuarios enviar y recibir mensajes (también denominados mensajes electrónicos o cartas digitales) mediante redes de comunicación electrónica. […] El primer mensaje de correo electrónico genuinamente enviado a través de una red data del año 1971. El mensaje, que contenía únicamente el texto «QWERTYUIOP», se envió a través de la red ARPANET.
2.10.2. BBS
Un Bulletin Board System o BBS (en español Sistema de Tablón de anuncios) es un software (un conjunto de programas informáticos instalados en un ordenador) que fue popular en las décadas de 1980 y 1990 en Estados Unidos para redes de ordenadores, ya que permitía a los usuarios participantes conectarse a través de una línea telefónica a una red donde podían ver y consultar distintas informaciones que publicaban usuarios participantes.
2.11. La World Wide Web
Tim Berners-Lee, un científico británico, inventó la World Wide Web (WWW) en 1989, mientras trabajaba en el CERN. La web se concibió y desarrolló originalmente para satisfacer la demanda de intercambio automatizado de información entre científicos de universidades e institutos de todo el mundo. El 30 de abril de 1993, el CERN colocó el software de la World Wide Web en el dominio público. Posteriormente, el CERN puso a disposición una versión con una licencia abierta, una forma más segura de maximizar su difusión.
<HEADER>
<TITLE>The World Wide Web project</TITLE>
<NEXTID N="55">
</HEADER>
<BODY>
<H1>World Wide Web</H1>The WorldWideWeb (W3) is a wide-area<A
NAME=0 HREF="WhatIs.html">
hypermedia</A> information retrieval
initiative aiming to give universal
access to a large universe of documents.<P>
Everything there is online about
W3 is linked directly or indirectly
to this document, including an <A
NAME=24 HREF="Summary.html">executive
summary</A> of the project, <A
NAME=29 HREF="Administration/Mailing/Overview.html">Mailing lists</A>
, <A
NAME=30 HREF="Policy.html">Policy</A> , November's <A
NAME=34 HREF="News/9211.html">W3 news</A> ,
<A
NAME=41 HREF="FAQ/List.html">Frequently Asked Questions</A> .
<DL>
<DT><A
NAME=44 HREF="../DataSources/Top.html">What's out there?</A>
<DD> Pointers to the
world's online information,<A
NAME=45 HREF="../DataSources/bySubject/Overview.html"> subjects</A>
, <A
NAME=z54 HREF="../DataSources/WWW/Servers.html">W3 servers</A>, etc.
<DT><A
NAME=46 HREF="Help.html">Help</A>
<DD> on the browser you are using
<DT><A
NAME=13 HREF="Status.html">Software Products</A>
<DD> A list of W3 project
components and their current state.
(e.g. <A
NAME=27 HREF="LineMode/Browser.html">Line Mode</A> ,X11 <A
NAME=35 HREF="Status.html#35">Viola</A> , <A
NAME=26 HREF="NeXT/WorldWideWeb.html">NeXTStep</A>
, <A
NAME=25 HREF="Daemon/Overview.html">Servers</A> , <A
NAME=51 HREF="Tools/Overview.html">Tools</A> ,<A
NAME=53 HREF="MailRobot/Overview.html"> Mail robot</A> ,<A
NAME=52 HREF="Status.html#57">
Library</A> )
<DT><A
NAME=47 HREF="Technical.html">Technical</A>
<DD> Details of protocols, formats,
program internals etc
<DT><A
NAME=40 HREF="Bibliography.html">Bibliography</A>
<DD> Paper documentation
on W3 and references.
<DT><A
NAME=14 HREF="People.html">People</A>
<DD> A list of some people involved
in the project.
<DT><A
NAME=15 HREF="History.html">History</A>
<DD> A summary of the history
of the project.
<DT><A
NAME=37 HREF="Helping.html">How can I help</A> ?
<DD> If you would like
to support the web..
<DT><A
NAME=48 HREF="../README.html">Getting code</A>
<DD> Getting the code by<A
NAME=49 HREF="LineMode/Defaults/Distribution.html">
anonymous FTP</A> , etc.</A>
</DL>
</BODY>
2.11.1. Red Gopher
Gopher es uno de los sistemas de Internet para divulgar información que precedió a la world wide web. Fue creado en 1991 en la Universidad de Minnesota y fue el primer sistema que permitió pasar de un sitio a otro seleccionando una opción en el menú de una página. Esa es la razón por la que adquirió mayor popularidad que sus competidores, que acabaron siendo sustituidos por la Web.
Los servidores Gopher, igual que los servidores FTP almacenan archivos y documentos que puede verse en línea o transferirse al PC.
2.11.2. Mosaic El Primer Navegador Gráfico
El navegador Mosaic o NCSA Mosaic fue el primer navegador web gráfico disponible para visualizar páginas web en sistemas operativos como Mac, Windows u otros. Este navegador web fue creado en enero de 1993, en el National Center for Supercomputing Applications (NCSA), por Marc Andreessen. […] En enero de 1997 se abandonó oficialmente el desarrollo de este navegador para dar paso al desarrollo de Netscape Navigator, de la empresa Netscape Communications fundada por los mismos creadores de Mosaic.
2.11.3. CSS
Antes del desarrollo de CSS, toda la información presentacional de los documentos HTML era incluida en el código HTML. Los colores de las fuentes, los estilos de fondo, la alineación de los elementos, los bordes y tamaños eran descritos explícitamente, a veces de manera redundante, dentro del HTML.
<body bgcolor="#000000" background="../../img/bg_stars.jpg" text="#ff0000" link="#ff4c4c" vlink="#ff4c4c" alink="#ff4c4c">
CSS permite a los diseñadores mover toda la información presentacional a otro archivo, la hoja de estilos, resultando en un código HTML notablemente más simple.
<style>
h1 {color: red}
</style>
[…] CSS fue propuesto por primera vez por Håkon Wium Lie el 10 de octubre de 1994. Al mismo tiempo, Lie trabajaba con Tim Berners-Lee en el CERN. Muchos otros lenguajes de hojas de estilos fueron propuestos al mismo tiempo, y las discusiones en las listas de correo públicas dentro del W3C dieron lugar a la primera Recomendación CSS por el W3C (CSS1) en 1996. En particular, la propuesta de Bert Bos fue influyente; él fue el coautor de CSS1 y es reconocido como el cocreador de CSS.
2.11.4. Javascript
JavaScript (abreviado comúnmente JS) es un lenguaje de programación interpretado, dialecto del estándar ECMAScript. […] JavaScript fue desarrollado originalmente por Brendan Eich de Netscape con el nombre de Mocha, el cual fue renombrado posteriormente a LiveScript, para finalmente quedar como JavaScript. . […] Desde el lanzamiento en junio de 1997 del estándar ECMAScript 1, han existido las versiones 2, 3 y 5 (la 4 se abandonó). En junio de 2015 se cerró y publicó la versión ECMAScript 6. […] Desde 2012, todos los navegadores modernos soportan completamente ECMAScript 5. Los navegadores más antiguos soportan por lo menos ECMAScript 3. La sexta edición se liberó en julio de 2015. […] La versión 7 de ECMAScript se conoce como ECMAScript 2016 y fue publicada en junio de 2016. Se trata de la primera versión para la que se usa un nuevo procedimiento de publicación anual y un proceso de desarrollo abierto.
<script>
document.body.appendChild(document.createTextNode('Hola Mundo!'));
var h1 = document.getElementById('header'); // contiene la referencia al tag <h1>
h1 = document.getElementsByTagName('h1')[0]; // accediendo al mismo elemento <h1>
</script>
2.11.5. Animación Flash (SWF)
A fines de la década de 1990, cuando el ancho de banda todavía era de 56 kbit/s para la mayoría de los usuarios de Internet, muchos artistas de animación de Adobe Flash emplearon animación limitada o animación recortada al crear proyectos destinados a la distribución web. Esto permitió a los artistas lanzar cortometrajes y experiencias interactivas muy por debajo de 1 MB, que podían transmitir audio y animación de alta calidad. Hasta la llegada de HTML5, mostrar el vídeo en una página web requería que el navegador disponga del plugin. En 2010, Apple criticó públicamente la aplicación de Adobe Flash de reproducción de vídeo por no tomar ventaja de la aceleración de hardware, además criticó toda la tecnología Flash en general, argumentando que no es un estándar abierto, y que afectaba el rendimiento de las baterías de sus equipos, razones por las que no lo incluirla en sus dispositivos móviles.
Flash Player fue descontinuado el 31 de diciembre de 2020 y su página de descarga desapareció dos días después. En octubre de 2020, Microsoft lanzó una actualización opcional KB4577586 que elimina Flash Player de Windows.
Flash fue un sistema para la creación de webs completamente dinámicas. con flash los diseñadores eran capaces de crear animaciones efectos interacción de una manera avanzada, pero sin necesidad de grandes complicaciones con el código.
También tenía un lenguaje de programación llamado ActionScript qué permitía a programadores realizar todo tipo de aplicaciones, interacción avanzada, comunicación cliente / servidor, etc.
Ostenta el mérito de haber sido precursor de muchas de las utilidades con las que cuentan hoy en día los estándares abiertos de la web, sin embargo era un sistema propietario qué acarreaba además diversos problemas para usuarios, dispositivos y sistemas informáticos que debían reconocer el contenido de las páginas hechas con Flash.
2.12. Aplicaciones Móviles
2.12.1. Psion Organizer
En 1984 Psion lanzó al mercado la que fue considerada como la primera PDA (Personal Digital Assistant) del mundo. Se llamaba Psion Organiser. No es que esta PDA fuera muy potente, pero tenía un software interno que incluía programas como un editor de texto, agenda, bloc de notas, base de datos de contactos, calculadora y otras funciones simples. De hecho, ni siquiera podías realizar o recibir llamadas con este aparato, pero sentaría las bases para las aplicaciones móviles del futuro.
2.12.2. Apple Newton
Esta PDA reconocía la escritura y podía conectarse directamente a ordenadores Mac, PC, siendo la precursora de la plataforma iOS. Además, también tenía acceso a una variedad de aplicaciones de proveedores externos, como, por ejemplo, un navegador web, Pocket Quicken (una aplicación para el control de las finanzas personales) o un cliente de email.
Este abuelo del iPhone se vendería entre 1993 y 1998 y, en su momento, fue un fracaso comercial ante la irrupción de equipos como la PalmPilot (1997) o los canadienses de BlackBerry (1999).
2.12.3. Nokia
En 1997 apareció el Nokia 6110. Sin embargo, este teléfono móvil tenía preinstalada la primera aplicación móvil de la historia que gozaría de un éxito mundial. El arrollador triunfo del juego de ‘La Serpiente’ sorprendió incluso a sus fabricantes.
2.12.4. Tecnología WAP
El nacimiento del WAP (2002) se lo debemos, entre otros, a Sony, Nokia, Motorola y Openwave. Estas cuatro compañías fueron las responsables de la creación de un estándar como el WAP, y que supuso el primer paso para conceder a los teléfonos móviles un completo acceso a internet, que finalmente culminó con la llegada del protocolo HTTP que domina en estos momentos.
<?xml version="1.0"?>
<!DOCTYPE wml PUBLIC "-//PHONE.COM//DTD WML 1.1//EN"
"http://www.pagina.com" >
<wml>
<card id="carta1" title="Carta">
<p mode="wrap">Un ejemplo para entrar a página.</p>
</card>
</wml>
Sin embargo, esto no triunfaría, ya que los desarrolladores encontraron grandes problemas a la hora de intentar adaptar el contenido a los múltiples tipos de pantallas de móviles. De esta época nos quedó como legado poder descargar distintos tonos de llamada y fondos de pantalla.
2.12.5. iPhone (2007)
El 29 de junio del 2007, Steve Jobs apareció en un escenario para presentar lo nunca visto hasta entonces. La joya de la corona: el iPhone. Apple crearía, en julio del 2008, la App Store, permitiendo a proveedores externos crear aplicaciones para ser comercializadas a través de ella. Arrancó con 500 aplicaciones en oferta.
2.12.6. Android (2008)
Google en 2008 lanzó el primer teléfono móvil con sistema operativo Android. Además de crear una tienda de aplicaciones denominada Android Market y que hoy conocemos como Google Play o Play Store. En sólo 4 años alcanzó las 700.000 aplicaciones.
2.12.7. BlackBerry
BlackBerry fue una marca de teléfonos inteligentes desarrollada por la compañía canadiense BlackBerry. Marcas como Nokia, HTC o incluso LG, sufrieron una decadencia principalmente por estancarse en lo que en el pasado les funcionaba como el teclado físico y ofrecer productos experimentales para el público. BlackBerry OS, quedaba corto en aplicaciones primordiales como WhatsApp, apps de mensajería, juegos y apps de utilidad.
2.12.8. Windows Phone
Windows Phone (abreviado WP) fue un sistema operativo móvil actualmente descontinuado,desarrollado por Microsoft como sucesor de Windows Mobile. A diferencia de su predecesor fue enfocado en el mercado de consumo en lugar del mercado empresarial. Con Windows Phone, Microsoft ofreció una nueva interfaz de usuario que integró varios de sus servicios activos. Compitió directamente contra Android de Google y iOS de Apple, con resultados poco alentadores. Su última versión fue Windows Phone 8.1, lanzado el 14 de abril de 2014.
2.12.9. Firefox OS
Firefox OS (nombre clave: Boot to Gecko o B2G) es un sistema operativo móvil descontinuado,basado en HTML5 con núcleo Linux, de código abierto para varias plataformas. Desarrollado por Mozilla Corporation bajo el apoyo de otras empresas y una gran comunidad de voluntarios de todo el mundo. El sistema operativo estuvo diseñado para permitir a las aplicaciones HTML5 comunicarse directamente con el hardware del dispositivo usando JavaScript y Open Web APIs.
2.13. El Futuro de las Aplicaciones Móviles
La aparición de las primeras aplicaciones móviles tenía como razón principal poder organizar el trabajo de ejecutivos y profesionales. Agendas, calculadoras, bloc de notas, editores de texto, hojas de cálculo, contactos, email, etc.
Sin embargo, con el paso del tiempo, el sector del entretenimiento fue tomando protagonismo. El teléfono móvil había dejado de ser un aparato con el que hacer y recibir llamadas y mensajes de texto para transformarse es una potente máquina, equiparable a un ordenador, con la que poder llevar a cabo casi cualquier tarea diaria.
Ahora, caminas por la calle y ves al 80% de la gente pendiente de su móvil. Escuchan música mientras corren o pasean; leen libros o noticias en el metro o autobús; comprueban si la meteorología les va a estropear los planes del fin de semana; disfrutan — y se enganchan — del último juego de moda… Pero, el mayor uso que le damos a nuestros teléfonos móviles, es el social.
Sin embargo, entre 2014 y 2018, las aplicaciones que han crecido más rápidamente son las que mejoran — y controlan — nuestra calidad de vida (apps para hacer la compra, para controlar y mejorar nuestro estado de salud, para regular la actividad deportiva…).
El futuro parece traer también las aplicaciones que nos servirán para controlar coches, casas… Y focalizadas en la temida y poderosa inteligencia artificial.
Hay algunos datos que parecen indicar la existencia de cierto agotamiento en el mercado de las aplicaciones móviles. No es que vayan a desaparecer, sino que se acerca una evolución hacia algo diferente, más centrado en la inteligencia artificial, la realidad aumentada (término que se usa para definir la visión de un entorno físico del mundo real, a través de un dispositivo tecnológico) y las aplicaciones en la nube.
Y es que las estadísticas indican que la mitad de las aplicaciones móviles descargadas se usan menos de 10 veces y tan solo el 53% de los usuarios se descargan una aplicación nueva al mes.
Las aplicaciones móviles del mañana, si quieren tener éxito, tendrán que centrarse en ser más rápidas, intuitivas y recolectar toda la información posible sobre el usuario, con la intención de desarrollar el producto que más se ajuste a su perfil.
2.14. Lectura Complementaria
Lecturas y actividades que pueden ayudar a dar contexto y ser de interés.
-
Libro Revolucionarios Cibernéticos [revolucionariosciber].
-
Libro Tejiendo la Web [tejiendolared].
3. Mundo Laboral y su Estado del Arte
El mundo laboral consiste en diversos escenarios posibles. En el siguiente capítulo se pondrá un breve resumen de lo actualmente disponible.
3.1. Trabajo Independiente (Freelance)
Un trabajador autónomo, trabajador por cuenta propia o simplemente independiente (en inglés, freelance), contratista independiente, es un trabajador que se desempeña de forma independiente, es decir, sin depender de otra organización, ofreciendo su fuerza laboral a clientes con libertad de condiciones.
Un autónomo es aquel que invierte su tiempo de acuerdo a sus necesidades y las de sus clientes. En muchos casos no cumplen horarios rutinarios o de oficina, tienen la autonomía de modificar su agenda de acuerdo a la carga de trabajo que posean y en la mayoría de los casos ofrecen sus servicios por medio de contratos, especificando el tiempo que trabajarán para el empleador y bajo qué condiciones.
3.1.1. Creación de una Empresa
Si bien es posible realizar boletas de honorarios, se recomienda la creación de una empresa cuando se disponga de un flujo constante de dinero (necesario para pagar las cotizaciones). Lo ideal es siempre contar con la asesoría de un contador profesional para realizar los trámites respectivos con impuestos internos (SII).
El tener una empresa ofrece diversos beneficios como:
-
Posibilidad de postular a proyectos en SERCOTEC.
-
Posibilidad de postular a https://www.mercadopublico.cl/
-
Posibilidad de comprar con factura.
-
Posibilidad de optar a créditos y ofertas especiales en instituciones bancarias.
-
Pago de cotizaciones y previsión de salud.
Lo ideal es tener una empresa si se quiere trabajar remoto a distancia para empresas internacionales.
3.1.2. Contratos
Lo recomendable es siempre realizar un contrato que estipule los derechos y deberes tanto del cliente como del proveedor. Tradicionalmente se firma una cláusula de NDA.
Un acuerdo de confidencialidad (ADC), acuerdo de no divulgación (en inglés non-disclosure agreement o NDA) se firman habitualmente cuando dos empresas o individuos acuerdan alguna relación comercial. Los acuerdos de confidencialidad pueden ser mutuos, de modo que las dos partes tienen restricciones de uso de la información proporcionada, o pueden afectar sólo a una de las partes.
También es común que un empleado firme un acuerdo de confidencialidad o acuerdo similar en el momento de su contratación.
La recomendación siempre es asesorarse con un abogado antes de elaborar o firmar un contrato. Hay empresas que incluso desean apropiar de los productos que se realizan en tiempos fuera del horario laboral. O exigir trabajar fuera de lo razonable sin pagar los valores respectivos. Siempre velar por los derechos laborales e intelectuales.
3.1.3. Ley de Chilena de Teletrabajo
Desde el Jueves 26 de Marzo de 2020 existe una nueva ley que regula el Teletrabajo y Trabajo a Distancia en Chile.
El empleador debe proporcionar los elementos de trabajo
Elementos tales como:
-
Un computador
-
Internet
Si un trabajador de su propia voluntad quiere utilizar su propio computador porque es una mejor solución para él, puede hacerlo, pero lo que no puede pasar es que el empleador obligue al trabajador a comprarse un computador o utilizar sus propios elementos de trabajo.
Derecho a desconexión digital
Empleador debe garantizar un mínimo de 12 horas continuas de desconexión.
Cumplir horario o libertad de horario
Se podrá establecer en esta modalidad
-
Tener horario establecido.
-
Tener libertad de horario.
Artículo 152 quáter J*
Si la naturaleza de las funciones del trabajador a distancia lo permite, las partes podrán pactar que el trabajador distribuya libremente su jornada en los horarios que mejor se adapten a sus necesidades, respetando siempre los límites máximos de la jornada diaria y semanal, sujetándose a las normas sobre duración de la jornada de los artículos 22 y 28 y las relativas al descanso semanal del Párrafo 4° del Capítulo IV del Libro Primero.
Accidente laboral y de trayecto trabajando desde casa
Quien trabaja desde su casa y tenga un accidente del trabajo o una enfermedad profesional, quedará cubierto por la mutualidad del empleador, por lo que en consecuencia tendrá derecho a los tratamiento que da la mutualidad y el pago de las prestaciones que da la mutualidad. Esto debe ser un accidente a causa del trabajo. El accidente de trayecto también queda cubierto, ya que esta ley permite combinar tiempo de trabajo presencial con tiempo de trabajo a distancia.
Privacidad
Malas prácticas como tener una cámara web encendida todo el día, aplicaciones que toman capturas de pantalla de tu computador, que miden el uso de teclado o que monitorean todo lo que haces en el computador son un peligro latente. ¿Qué pasa con esto?
No se puede violar la intimidad ni la privacidad de las personas. Los mecanismos de control que el empleador puede tener son los que respetan los derechos fundamentales de las personas, que respetan los derechos laborales. Esto ya está regulado por dictámenes de la Dirección del Trabajo hace mucho tiempo.
3.1.4. Ética Laboral
En muchas ocasiones nos enfrentaremos a un dilema ético - moral. Donde se solicitarán la ejecución de acciones que probablemente sean ética y moralmente cuestionables.
Tomemos como ejemplo el caso de La Polar, donde se realizó la repactación unilateral y abusiva de las deudas de alrededor de 1 millón de clientes. Los consumidores se quejaron de que en sus cuentas aparecían reprogramaciones que nunca habían aceptado, con cuotas y montos que eran fijados por la empresa y encarecerían excesivamente la deuda, o bien se enteraban de ello tras recibir cartas de cobranza o aparecer en Dicom.
Los ejecutivos que solicitaron el proyecto fueron los mayores imputados por estas malas prácticas. Pero el equipo de tecnología fue quien logró que los sistemas de software cumplieran las características solicitadas. Un sistema de software, sobre todo en empresas que administra dinero y deudas, es laboriosamente auditado, detallado y analizado. El equipo de tecnología sabía perfectamente las consecuencias de ejecutar las órdenes solicitadas y aún así implementó los sistemas para lograr esas malas prácticas.
Siempre puedes utilizar la Objeción de conciencia para no participar en proyectos o realizar acciones que sus consecuencias entren en conflicto con tu marco ético - moral. Muchas veces es una decisión difícil (puede que te cueste el puesto de trabajo).
Existe un texto que es atribudo a Al-Juarismi; Matemático, geógrafo y astrónomo de una talla intelectual extraordinaria que vivió entre los años 780 y el 850 de nuestra era. Aunque no es posible verificar que realmente sea de su autoría, su contenido es importante de destacar.
A la pregunta que le hacen, sobre el valor del ser humano, este responde: "`Si tiene ética entonces su valor es igual a 1 (uno). Si además es inteligente, agréguele un cero y su valor será igual a 10. Si también es rico, añádale otro cero y su valor será de 100. Si además tiene bello aspecto, agréguele otro cero y su valor será igual a 1000. Pero si pierde el 1 (uno), que corresponde a la ética, perderá todo su valor, pues solamente le quedarán los ceros. Así de sencillo: Sin valores éticos, ni principios sólidos, lo único que queda son delincuentes, corruptos y personas que no valen nada"`
Ley 19.223
La Ley 19.223 tipifica figuras penales relativas a la informática en Chile.
3.1.5. Elegir un Computador
El computador de un desarrollador debería cumplir el principio de Pareto. Esto quiere decir que pueda realizar al menos el 80% de los proyectos con el mismo equipo. Para el caso de un desarrollador web/móvil, un computador Apple es la opción más versátil. Permite desarrollar para Web, Android e iOS, además de poder ser instalado distribuciones Linux.
Debe tener las siguientes características:
-
Tener máximo 5 años de antigüedad (2 a 3 como recomendado, nuevo ideal).
-
Tener procesador M1 o superior.
-
Tener 8 GB de Ram o Superior (16 GB o más Recomendado).
-
Tener un disco duro SSD de 256 GB (500 GB o Superior recomendado).
-
Si es un computador portátil fijar que la batería tenga menos de mil (1000) ciclos.
Tiendas
Opciones
-
Mac Mini: Ideal para comenzar, rangos de precios más razonables si se compra usado.
-
Macbook Air: Similar a Mac Mini, pero con pantalla incluida y portabilidad.
-
Macbook Pro: La opción más adecuada para desarrollo móvil.
Dispositivos Móviles
Se recomienda comprar un smartphone destinado a pruebas. De preferencia uno de 2 a 3 años de antigüedad. Considerar que los mercados para desarrollo móvil es recomendable probar dispositivos al menos 3 versiones anteriores a la última disponible, para asegurar la compatibilidad con los dispositivos más antiguos.
3.2. ¿Qué significa ser Full Stack (Generalista)?
Cuando las empresas buscan a un Full Stack ("generalista"), en realidad lo que están buscando es alguien que les pueda resolver sus problemas utilizando una serie de herramientas pre-definidas. Normalmente alguien que pueda participar en la elaboración de una aplicación desde la fase de toma de requerimientos hasta la fase de paso a producción y mantenimiento.
Muchas veces se confunde este concepto con alguien que es un "Maestro Chasquilla" o "Jack of All Trades". Hace de todo un poco, pero sabe poco y sin conocimiento profundo de los temas. Si no tienes cuidado puedes terminar siendo una persona con mucha experiencia, pero no experticia suficiente como para competir en cargos semi senior o senior, incluso con varios años en la industria.
Lo ideal es que elijas un conjunto de herramientas que te sirva para resolver problemas de diversa índole y te conviertas en un experto usándolas. Por ejemplo seleccionas un stack de backend y un framework especifico (ej: elixir, golang, rust, python, php, js, ruby), un stack de frontend (ej: liveview, svelte, vue, react), una base de datos (ej: postgres, sqlserver) y un proveedor de servicios (como amazon, firebase, google cloud, etc). Al realizar los proyectos con la mismas herramientas, poco a poco irás generando experticia y dominio de los temas. Podrás competir con niveles semi senior o senior. Evita tener un currículum desparramado por todos lados.
Puedes ser generalista en el sentido de que estás capacitado para elaborar una aplicación desde el inicio hasta el final, pasando por el diseño del sistema, las bases de datos, interfaces de usuarios, configuración de servidores y dominio de las reglas de negocio. Pero siempre con un stack determinado en el cual lo conozcas de principio a fin. Esto te evitará maratones de "Aprender sobre la marcha" y sorpresas a las 3 Am del fin de semana. Sin embargo, también realizar proyectos y experimentos con nuevas tecnologías y estrategias es importante o se corre el riesgo de estancarse. Siempre ser flexible y estar abiertos al cambio, de forma estratégica y controlada.
3.2.1. Algunas Combinaciones Full-Stack
Lenguaje | Backend | Frontend |
---|---|---|
Vue.js / Inertia.js / Livewire |
||
RedWood.js / Next.js / Nest.js |
||
Stack Sugerido
El Stack predilecto del profesor es: Elixir, PHP y Swift debido a que permite abordar gran cantidad de casos de uso, utilizando tecnologías modernas y versátiles. Siguiendo el principio de Pareto de 80/20.
Tecnología | Descripción |
---|---|
Elixir + Postgres: Phoenix |
Permite elaborar sistemas de backend y frontend sofisticados y modernos. Incluso proyectos de IOT, Machine Learning, Mobile, Web Assembly, entre otros. Preparados para alta escalabilidad y concurrencia. |
PHP + MySQL: ProcessWire / Laravel / Wordpress |
Permite elaborar sitios webs rápidamente para entornos de hosting con Cpanel, utilizando las capacidades CMS/CMF de los frameworks. |
Javascript + Inertia.js + Svelte.js + Esbuild: Web |
Es el lenguaje predilecto para crear animaciones y manipulación del DOM. Si bien puede ser utilizado en otras áreas, se recomienda utilizarlo solamente para el ambiente web, ya que existen opciones más adecuadas para backend. |
C / Rust / Zig: Low Level |
Permite elaborar aplicaciones de bajo nivel, sobre todo extensiones para Elixir u otros lenguajes. También recomendado para entornos con Web Assembly. |
Swift: iOS, Kotlin: Android. |
Permite crear aplicaciones móviles nativas, en un ecosistema integrado y robusto. De preferencia elegir nativo sobre otras opciones como React Native o Flutter. |
Wren / C#: Videojuegos |
Utilizar estos lenguajes para realizar videojuegos con TIC80, DOME, Unity, Godot u otro engine. |
Bash / Python / AWK / Go: Scripts y CLI |
Utilizar para elaborar scripts de sistema y utilidades simples o para Devops. |
3.2.2. Habilidades con forma de "T" y "M"
Las personas en forma de T son empleados con amplia experiencia en diferentes disciplinas (que se ilustra con la barra horizontal de "T") y tienen una gran experiencia en su campo o disciplina (que se representa con la barra vertical de "T"). Por lo tanto, las personas con forma de T tienen una especialidad y, además, tienen una experiencia más amplia con otras habilidades.
A diferencia de la forma de T, la forma de M tiene dos barras verticales. Esas barras representan a personas con múltiples conocimientos en sus campos o disciplina. Una persona con más de una especialidad. Los empleados en forma de M tienen el mismo conocimiento, o más, en las habilidades que se esperan de los empleados en forma de T, y los empleados en forma de M a menudo son miembros de equipos multifuncionales de alto rendimiento.
3.2.3. La práctica hace al maestro
Un pianista concertista practica varias horas al día, aprendiendo música, practicando ejercicios y mejorando sus habilidades. Entrena la misma pieza musical una y otra vez hasta aprender cada pequeño detalle hasta lograr la interpretación musical indicada. Por que cuando sea el momento de presentarse ante un público, el pianista desea entregar su mejor interpretación posible. Desea estar orgulloso y justificar tanto el dinero como el tiempo que han invertido las personas para oirlo en su presentación.
Un jugador de fútbol profesional pasa horas en el gimnasio, corriendo, alimentándose adecuadamente y haciendo diversos ejercicios físicos una y otra vez hasta ser un maestro. Verá grabaciones de partidos anteriores y estudiará estrategias sobre como mejorar. También jugará partidos de exhibición y amistosos para prepararse para los partidos de campeonato.
Un karateka constantemente está practicando katas (movimientos que imitan una secuencia de batalla), cómo respirar y flexionar los músculos en el tiempo correcto. Realizando los movimientos innumerables veces, mejorando en cada repetición.
Los mejores desarrolladores tienen la misma forma de ver la profesión. No van a trabajar todos los días y practicar a expensas del empleador. Van e invierten tiempo personal en aprender nuevas herramientas, lenguajes y perfeccionar sus técnicas y conocimientos. Siempre se aprenderá nuevas cosas en el trabajo, pero como hay dinero de por medio está la expectativa de que se va a producir, no a practicar.
Fragmento de: Brian P. Hogan. Exercise for Programmers.
En palabras simples. Si seguimos una Distribución Normal, debes posicionarte más alla del promedio (13.6% o más) hacia la derecha. De esta forma podrás superar la constante batalla de competencia al buscar un trabajo.
3.2.4. Seniority
En muchas empresas se habla de distintos niveles de seniority (Junior, Engineer, Senior Engineer, etc.). Sin embargo es un concepto muy ambigüo ya que varía entre cada empresa. Para poder estandarizar un poco, se debe detallar lo que se espera de un profesional en cada nivel.
Es la responsabilidad de la empresa y del equipo de trabajo proveer un ambiente donde cada persona sea empoderada para ser y crecer al nivel mundial (world-class) en su rol y habilitarlos para alcanzar más de lo que pensaban posible para ellos mismos.
Lo importante es que el profesional tome las riendas de su carrera y dirija su evolución según sus criterios, nunca dejar que una empresa defina tu carrera y sea la única fuente de crecimiento profesional.
3.3. Tipos de Empresa
3.3.1. Moledora de carne (☠️)
Esta empresa se dedica a la subcontratación. Clientes vienen y les piden personal para elaborar un proyecto. Normalmente, no tienen muy buenas prácticas y tu sueldo no será el mejor (aunque ellos cobrarán mucho más). El contrato será con la moledora y no con la empresa a la cual realizas el proyecto. Usualmente, te tocan proyectos cachos que nadie más quiere hacer con tecnologías, plazos o condiciones antiguas y adversas. Alta probabilidad de Burn Out.
Se les dicen moledoras de carne porque te exprimen cada gota de sudor y sangre de ti, para que finalmente te desechen si ya no soportas las condiciones tóxicas de su ambiente.
Hay empresas de subcontratación decentes, pero tienes que hacer un proceso de investigación correspondiente antes de aceptar ingresar a ese tipo de empresas.
La mayoría de las moledoras trabajan con clientes que exígen ciertos requisitos. Mientras más títulos y certificaciones tengas, más dinero le podrán cobrar al cliente, por lo que si deseas trabajar en este tipo de organización procura tener buenas certificaciones y estudios.
Tecnologías Comunes
Los proyectos en este tipo de empresa son usualmente para bancos, instituciones de salud, gobierno u otras instituciones de gran envergadura y antigüedad. Por lo que las tecnologías usadas estarán dentro del ámbito Microsoft/Oracle/IBM.
-
Java con Spring, Springboot o Struts.
-
C# con ASP.NET.
-
PHP (Proyectos Legacy).
-
Visual Basic 6
-
Cobol
-
SQLServer
-
Oracle
3.3.2. Startup
Empresas que tienen poco capital y experiencia en el mercado. Alto riesgo. Normalmente, dependen de algún fondo como CORFO o de inversionistas privados. Alta probabilidad de que te paguen poco o nada. Muy inestables ya que dependen de factores ajenos a su control (como que su producto sea un éxito, inversionistas den más dinero). Probablemente te ofrezcan un porcentaje de la empresa a cambio de un sueldo ínfimo o cosas como pizza, cervezas y oficinas "entretenidas". No es recomendable aceptar este tipo de ofertas, ya que la mayoría de las startups perecen en los primeros años.
También suelen tener roles poco definidos y se deba realizar labores ajenas a tu área. También la posibilidad de marchas de la muerte seguidas para cumplir los caprichos de los inversionistas y las postulaciones a fondos.
Investigar y evaluar si trabajar en estas condiciones vale la pena. De preferencia buscar Startups con una liquidez ya consolidada para evitar problemas al recibir sueldos.
Normalmente, las startups tienen tan poco presupuesto que cualquier persona que pueda hacer el trabajo es aceptada. Idealmente procura conocer bien las herramientas y prepárate para aprender de muchas áreas distintas. Trabajar para startups es ideal para personas que deseen armar su propia startup en el futuro, si son afortunados, tendrán buenas experiencias y podrán conocer las distintas áreas del negocio, hacer contactos y los requisitos para tener una empresa propia.
Burn Rate
Una cosa que debes saber y tener presente es el Burn Rate de la Startup. Básicamente es la comparación de cúanto dinero existe en las arcas de la empresa versus cúanto dinero se quema mensualmente para mantenerla a flote. Mientras más alto sea el Burn Rate más rápido la empresa se quedará sin dinero y deberá buscar inversionistas o formas de generar ingresos. Si la empresa no te da esta información actualizada y de forma constante considéralo como una red flag. Las personas tienen derecho a conocer y poder planificar su situación laboral con tiempo, si es que la organización da indicios de no poder seguir funcionando.
Adquisiciones
Una gran parte de las Startups tiene por objetivo ser compradas por empresas más grandes. Ten en consideración de que las condiciones de compra pueden no favorecerte. Si la empresa es adquirida por otra, la nueva empresa no está obligada a darte ningún tipo de compensación y puede despedirte sin aviso. Ten siempre en bandeja una alternativa laboral y colchón de ahorros para mantenerte a flote si pierdes el trabajo.
Enlaces a Startups en Chile
3.3.3. Agencia de marketing
Estas empresas se dedican a realizar sistemas para campañas publicitarias o apoyo a estas. Páginas webs, captación de usuarios y sistemas de análisis de campañas son proyectos comunes. El principal drama son los plazos extremadamente acotados (2 a 3 semanas) para sistemas completos. El burn out es muy probable y la calidad del software que se realice debido a estos plazos es cuestionable.
Antes de entrar a una agencia procura que cumplan con un buen stack tecnológico y de gestión de proyectos. Con sueldos apropiados. Mucha de estas agencias utilizan la técnica de contratar prácticantes universitarios y elaborar todos los proyectos con una alta rotación de personal. Su prioridad es cumplir con lo que se le prometió al cliente, con el menor plazo y coste posible.
Haz una buena investigación y obtención de referencias antes de entrar.
Al igual que las startups, mientras el trabajo pueda cumplirse a tiempo y con la menor cantidad de defectos posibles. Idealmente conocer sobre marketing, copywriting, usabilidad y diseño ayuda.
Tecnologías Comunes
-
Plataformas No-Code como Bubble.
3.3.4. Software factory y contratistas
Similar a la agencia de marketing, existe la fábrica de software. Se diferencian por que su foco no es la publicidad, pero si la elaboración de sistemas de software. Ten cuidado ya que muchas al igual que la agencia, prioriza plazos cortos y bajos costos frente a la calidad del software y la calidad de vida de las personas. Las empresas contratistas normalmente tienen a uno o varios clientes a los cuales les ofrecen servicios de desarrollo y soporte. Los clientes normalmente son bancos, retail o instituciones de servicios públicos.
Haz una buena investigación antes de entrar sobre sus prácticas laborales, sueldos e historia.
Normalmente, realizan una prueba técnica antes de entrar. Se recomienda conocer bien un área como frontend o backend. Además de conceptos de DDD, Solid y Patrones de Diseño.
Tecnologías Comunes
-
Java con Spring, Springboot o Struts.
-
C# con ASP.NET.
-
PHP, Javascript (Next.js, Nuxt.js).
3.3.5. Pymes y ONGs
Las pequeñas y medianas empresas u organizaciones no gubernamentales pueden variar en los sueldos y proyectos que pueden ofrecer. Todas necesitan servicios informáticos para gestionar mejor sus organizaciones. Investiga bien si el sueldo ofrecido cumple tus necesidades, o si la causa de la ONG te motiva a ayudarlos.
Similares a la startup, son recomendables para personas que deseen practicar sus habilidades y elaborar proyectos con una causa más elevada.
Tecnologías Comunes
3.3.6. Bancos y minería
En los bancos y otras instituciones financieras o mineras te puedes encontrar con tecnologías antigüos (sistemas legacy como AS400, Cobol, Visual Basic 6, Dbase, Sybase). Pero también (dependiendo del banco) prácticas y tecnologías más modernas. Los bancos suelen trabajar con tecnologías en las cuales una empresa internacional como Oracle, IBM, Microsoft, SAP, ofrece soporte técnico y capacitación. Pagan millonarias sumas por licencias.
El riesgo que tiene esta empresa es quedarse estancado con tecnologías empresariales. Ofrecen relativa estabilidad pero tienen prácticas como vestir formal que poco a poco se estan diluyendo. Ve a este tipo de empresas si deseas dar mantención a sistemas antiguos y una estabilidad laboral con sueldos aceptables, pero proyectos quizás menos entretenidos.
La mayoría requiere de título universitario en el área informática o relacionado, para ser aceptado.
Burocracia considerable.
Tecnologías Comunes
-
Java
-
Oracle DB
-
Cobol
-
.NET
-
SAP
-
Angular
-
Gestión de Proyectos
3.3.7. Instituciones estatales
Instituciones como Hospitales, Cámara de Diputados, Registro civil y otros relacionados. Cuentan con departamentos de informática. Las principales labores son soporte técnico (reparar computadores, redes y equipos de oficina, gestionar sistemas de información, dar asesoría técnica a los usuarios). Gran parte de sus sistemas son elaborados por contratistas, el desarrollo interno no es mucho (aunque depende de cada institución).
El título universitario puede ser opcional, sin embargo tener uno puede significar la diferencia entre ganar el sueldo mínimo y tres veces más. Ya que las remuneraciones están basadas en grados y un título da muchos puntos para mejorar el grado.
Usualmente dan contratos a plazo fijo y reemplazos antes de darte un cupo definitivo. Una vez que tienes contrato indefinido puedes tener pega por muchos años. Pero igualmente puedes estar años esperando ese cupo.
Los sueldos no son los mejores, pero si se puede hacer carrera y subir el sueldo con los años y estudios.
Mucho de los procesos ya están pensados, la burocracia es alta.
Tecnologías Comunes
-
Gestión de proyectos
-
Análisis y Diseño de Sistemas
-
Base de datos
-
.NET
-
Java
-
PHP
3.3.8. Transporte, retail y servicios básicos
Similares a los Bancos e Instituciones Estatales. Las empresas de servicios básicos como agua, luz, gas, internet o de retail como Fallabela o aerolíneas como LAN, cuentan con sistemas legacy y alguno que otro proyecto con nuevas tecnologías. Muchas veces conviene más ser contratista de estas empresas a ser contratado directamente. La recomendación es trabajar como empleado un par de años para conocer su ambiente, además de tener contactos y luego fundar una empresa que les brinde servicios adaptados a sus necesidades.
Tecnologías Comunes
Similar a software factory, los bancos o instituciones estatales.
3.3.9. Escuelas de educación básica, media
Al igual que con las instituciones estatales, las escuelas de educación básica y media tienen un área informática. Normalmente, dedicada a la gestión de los equipos computacionales y solución de problemas de los usuarios. Quizás tengan sistemas para la gestión de notas, página web y otros como Moodle. Los sueldos no son muy elevados (dependiendo del lugar), pero tiene el plus de estar aportando en hacer una diferencia en la vida de los jóvenes. Si deseas hacer clases o participar en un proyecto educativo quizás este tipo de organización sea para ti. No es necesario tener un título relacionado a la informática, pero si sería de mucha ayuda uno relacionado a la educación. Podrías entrar como servicio técnico con un par de certificaciones técnicas. Aunque si deseas hacer clases, una carrera o magíster en docencia es de ayuda.
Tecnologías Comunes
-
PHP (Moodle)
-
Java
-
.NET
3.3.10. Universidades e institutos
En las universidades se puede trabajar como profesor (de preferencia con un magister en educación) o como miembro del equipo de TI. Las labores son similares a una escuela de educación media y organizaciones estatales. Existen algunas universidades que tienen áreas de investigación y desarrollo que también se puede participar, como por ejemplo el Laboratorio Nacional de Computación de Alto Rendimiento (NLHPC).
Tecnologías Comunes
-
Magíster en Matemática, Física, Estadísticas, Astronomía, Docencia
-
Python, .NET, Java
-
PHP (Moodle)
3.3.11. Empresas con producto y/o servicio definido
Normalmente, comenzaron como una Startup, pero llevan más de 5 años y tienen una buena salud financiera. Su producto o servicio es rentable y tiene ingresos constantes. Entra a esta organización si te gusta el servicio o producto que tienen y vez aportando a su evolución.
Se diferencia del software factory porque la mayor parte de sus proyectos están relacionados del producto o servicio en vez de un cliente externo. Por ejemplo armar un dashboard que tenga indicadores sobre el avance del producto, mejorar los sistemas de comunicación interna y otros.
Tecnologías Comunes
Similar al software factory y Startup.
3.4. Conseguir empleo
Se recomienda tomar las siguientes acciones:
-
Participar en comunidades de desarrolladores, ampliando la red de contactos. Los mejores empleos son cuando un amigo te recomienda, saltándose ampliamente el proceso de contratación.
-
Elaborar un portafolio de proyectos y promocionarlos (sin seguir tutoriales).
-
Asistir a charlas y conferencias y realizar networking.
-
Practicar Algoritmos y Coding Challenges (https://exercism.org/, https://leetcode.com/).
-
Practicar Diseño de Sistemas, DDD, Solid, Hexagonal.
-
Practicar responder preguntas con el método STAR.
-
Tener un CV bien redactado, estructurado, honesto y orientado al puesto laboral.
-
Elaborar una carta de presentación.
-
Ser resiliente y postular (En promedio 50 postulaciones entregarán resultados).
-
Escuchar Podcast de tecnología y estar atentos a las nuevas tendencias.
3.4.1. Tener Experiencia Internacional
El trabajar para empresas del extranjero permitirá obtener experiencias únicas que darán un gran peso al currículum. Para esto se recomienda aprender bien inglés (o el idioma predilecto de la empresa o país). Chile tiene varios convenios con distintos países, lo que se conoce como Work and Holiday o tomar cursos de maestrías o inglés afuera.
3.4.2. Estar Atento a los Ciclos
La industria tecnológica vive procesos cíclicos constantemente. Por ejemplo a principio de los 2000 se experimentó lo que fue la Burbuja Punto Com. Donde al principio hubo amplias contrataciones y luego tremendos despidos. Lo mismo sucedió en la época de la pandemia del 2020, donde las empresas comenzaron a contratar masivamente, para luego entrar a un proceso de despidos masivos. Actualmente, las empresas han comenzado a reiniciar sus procesos de contratación y tener un ritmo a niveles previos a la pandemia.
3.4.3. Importancia de los Fundamentos
Lo importante es tener confianza en las habilidades duras (técnicas) y blandas (comunicación, emocional, resiliencia, saber aprender), además de tener redes de contacto. El tener fundamentos sólidos en lo técnico y en lo profesional, permitirá saber ajustarse, adaptarse y acomodarse a los requisitos de la época y contexto tecnológico-social.
3.4.4. Comunidades en Chile
3.4.5. Eventos y Meetups
3.4.6. Noticias
3.4.7. Plataformas de Aprendizaje
3.4.8. Empleos con Contrato
3.4.9. Empleos como Freelance
4. Patrones y Arquitecturas de Software
Un estilo arquitectónico establece un marco de referencia a partir del cual es posible construir aplicaciones que comparten un conjunto de atributos y características mediante el cual es posible identificarlos y clasificarlos.
4.1. Arquitectura en Capas
La arquitectura en capas es una de las más utilizadas, no solo por su simplicidad, sino porque también es utilizada por defecto cuando no estamos seguros que arquitectura debemos de utilizar para nuestra aplicación.
La arquitectura en capas consta en dividir la aplicación en capas, con la intención de que cada capa tenga un rol muy definido, como podría ser, una capa de presentación (UI), una capa de reglas de negocio (servicios) y una capa de acceso a datos (DAO), sin embargo, este estilo arquitectónico no define cuantas capas debe de tener la aplicación, sino más bien, se centra en la separación de la aplicación en capas (Aplica el principio Separación de preocupaciones (SoC)).
En la práctica, la mayoría de las veces este estilo arquitectónico es implementado en 4 capas, presentación, negocio, persistencia y base de datos, sin embargo, es habitual ver que la capa de negocio y persistencia se combinan en una solo capa, sobre todo cuando la lógica de persistencia está incrustada dentro de la capa de negocio.
Un detalle a tener en cuenta en esta arquitectura, es que cada capa debe de ser un componente independiente, de tal forma que se puedan desplegar por separado, incluso, es habitual que estos componentes residan en servidores separados pero que se comunican entre sí.
Referencias
4.2. Monolito
El estilo arquitectónico monolítico consiste en crear una aplicación autosuficiente que contenga absolutamente toda la funcionalidad necesaria para realizar la tarea para la cual fue diseñada, sin contar con dependencias externas que complementen su funcionalidad. En este sentido, sus componentes trabajan juntos, compartiendo los mismos recursos y memoria. En pocas palabras, una aplicación monolítica es una unidad cohesiva de código.
Una falsa creencia es que, una aplicación monolítica es un caos por dentro, donde todo el código está amontonado, no hay una estructura clara y que por lo general tiene miles de clases u objetos, sin embargo, esto es solo una mala fama que se le ha dado, si bien es verdad que se podía dar el caso, recordemos que eso también se podría dar en cualquier estilo de arquitectura, pues eso dependen más bien del programador y no del estilo arquitectónico.
Otra falsa creencia es creer que las aplicaciones Monolíticas son solo las aplicaciones grandísimas que hacen un montón de cosas, pero lo cierto es que un monolítico puede ser de una sola clase, o de miles, lo que define un estilo monolítico no es el número de clases, archivos o líneas de código, lo que lo define es que es autosuficiente, es decir, que tiene toda la funcionalidad para operar por sí mismo y sin depender de nadie más.
En la imagen podemos apreciar cómo funciona el proceso de compilación de una aplicación Monolítica, el cual todos los paquetes junto con sus dependencias son compilados y da como resultado un solo artefacto, el cual incluye todo el código junto con las dependencias. En este ejemplo decimos que hemos creado un EXE, pero se pudo haber creado un Jar en el caso de Java o un JS en el caso de JavaScript, dependiendo la tecnología utilizada tendremos un artefacto diferente, pero al final, todos contendrán todo el código con sus dependencias.
Referencias
4.3. Microservicio
El estilo de Microservicios consiste en crear pequeños componentes de software que solo hacen una tarea, la hace bien y son totalmente autosuficientes, lo que les permite evolucionar de forma totalmente independiente del resto de componentes.
Un Microservicios es un pequeño programa que se especializa en realizar una pequeña tarea y se enfoca únicamente en eso, por ello, decimos que los Microservicios son Altamente Cohesivos, pues toda las operaciones o funcionalidad que tiene dentro está extremadamente relacionadas para resolver un único problema.
En este sentido, podemos decir que los Microservicios son todo lo contrario a las aplicaciones Monolíticas, pues en una arquitectura de Microservicios se busca desmenuzar una gran aplicación en muchos y pequeños componentes que realizar de forma independiente una pequeña tarea de la problemática general.
4.4. Otros tipos de Arquitectura
4.5. Patrón Modelo Vista Controlador
MVC (Modelo-Vista-Controlador) es un patrón en el diseño de software comúnmente utilizado para implementar interfaces de usuario, datos y lógica de control. Enfatiza una separación entre la lógica de negocios y su visualización. Esta "separación de preocupaciones" proporciona una mejor división del trabajo y una mejora de mantenimiento. Algunos otros patrones de diseño se basan en MVC, como MVVM (Modelo-Vista-VistaModelo), MVP (Modelo-Vista-Presentador) y MVW (Modelo-Vista-Whatever).
El patrón Modelo-Vista-Controlador (MVC), es uno de los primeros que se debería aprender. Es tan fundamental que ha sobrevivido décadas en la industria y sus ideas se han esparcido por muchas plataformas. Es el padre de muchos otros patrones derivados como MVVM (Modelo-Vista-VistaModelo), entre otros.
Este patrón es esencial debido a que ayuda a responder una de las preguntas más comunes: ¿Dónde debería poner esta pieza de código?.
El patrón MVC es uno de arquitectura. Entrega un mapa de la estructura de la aplicación y como su nombre dice, consiste en tres capas: modelo, vista y controlador.
El siguiente diagrama de Apple muestra un poco la relación de las vistas y controladores.
El principal problema de MVC y por qué razón nacieron otros patrones derivados es debido a la tendencia de que los controladores crecían de forma exponencial. Incluso llegando a ser llamado Massive View Controllers, por la cantidad de responsabilidades que tenían que cumplir.
4.5.1. Modelo
La capa modelo (model), es la capa que maneja los datos y la lógica de negocios, independiente de su representación visual. Define qué datos debe contener la aplicación. Si el estado de estos datos cambia, el modelo generalmente notificará a la vista (para que la pantalla pueda cambiar según sea necesario) y, a veces, el controlador (si se necesita una lógica diferente para controlar la vista actualizada).
Volviendo a nuestra aplicación de lista de compras, el modelo especificará qué datos deben contener los artículos de la lista (artículo, precio, etc.) y qué artículos de la lista ya están presentes.
4.5.2. Vista
La capa vista (view) es la que muestra la información al usuario y permite interacciones, independiente de la capa de datos. La vista define cómo se deben mostrar los datos de la aplicación. En nuestra aplicación de lista de compras, la vista definiría cómo se presenta la lista al usuario y recibiría los datos para mostrar desde el modelo.
4.5.3. Controlador
La capa controlador (controller) es la que actúa como puente entre modelo y vista. Almacena y manipula el estado de la aplicación y proporciona datos a las vista, interpreta las acciones del usuario según las reglas de negocio. El controlador contiene una lógica que actualiza el modelo y/o vista en respuesta a las entradas de los usuarios de la aplicación.
Entonces, por ejemplo, nuestra lista de compras podría tener formularios de entrada y botones que nos permitan agregar o eliminar artículos. Estas acciones requieren que se actualice el modelo, por lo que la entrada se envía al controlador, que luego manipula el modelo según corresponda, que luego envía datos actualizados a la vista.
Sin embargo, es posible que también se desee actualizar la vista para mostrar los datos en un formato diferente, por ejemplo, cambiar el orden de los artículos de menor a mayor precio o en orden alfabético. En este caso, el controlador podría manejar esto directamente sin necesidad de actualizar el modelo.
4.6. Patrón Modelo Vista Vista-Modelo
El patrón Modelo-Vista-VistaModelo (MVVM), es un patrón de arquitectura que facilita estructurar la aplicación dividiéndola en tres roles.
-
El modelo (model): representa los datos y lógica de negocio de la aplicación.
-
La vista (view): Muestra la información al usuario y permite la interacción.
-
La vista-modelo (view-model): Actúa como puente entre las capas de vista y modelo. Contiene el estado de la vista y maneja la lógica de interacciones.
4.6.1. ¿Diferencias entre MVC y MVVM?
Al comparar los patrones de MVC y MVVM es notable la similitud y son casi idénticos.
La principal diferencia radica en que MVC hace énfasis en los controladores. Encargados de manejar las interacciones para varias vistas. En cambio en MVVM la vista-modelo es un único componente que controla el comportamiento y estado de una única vista. Comúnmente representado como un componente.
Otra diferencia es la forma de comunicación entre la vista y su controlador. En MVC la vista y el controlador tienen funciones definidas que son llamadas de forma imperativa para informar sobre una acción o requerir actualizar la información en la vista. Por otra parte en MVVM la vista y la vista-modelo están unidas por un mecanismo de enlazado (binding) que automáticamente informa sobre interacciones realizadas en la vista y cambios ocurridos en la vista-modelo. Estos mecanismos de enlazado varían según la plataforma.
Las capas de MVC interactúan y son interpretadas dependiendo de algunos factores como:
-
La plataforma donde se implementa.
-
La experiencia del profesional y su interpretación del patrón.
-
La moda del día (Los devs igual pueden seguir modas).
El patrón Modelo-Vista-VistaModelo (MVVM) es principalmente una versión de MVC bajo un nombre diferente.
Si bien hay ligeras diferencias, perfectamente se pueden utilizar los conceptos de MVC y MVVM de forma unificada sin problemas.
4.7. La Importancia de MVC y MVVM
El utilizar un patrón de arquitectura como MVVM con roles claramente definidos nos ayudan cumplir principios de diseño como la separación de conceptos. Lo que es una piedra angular para mantener código bien organizado, fácilmente entendible y que sus pruebas unitarias son viables de implementar.
Utilizar patrones de arquitectura como MVVM es sumamente importante. A pesar de que los frameworks otorgen herramientas innovadoras para elaborar aplicaciones, si no utilizamos patrones de arquitectura el código se irá acumulando, aumentando de complejidad, para finalmente crear monolitos masivos que son difíciles de mantener y probar.
El hecho de que algunos frameworks manejen automáticamente la actualización de las vistas no justifica abandonar las buenas prácticas en el desarrollo de software que han existido por décadas en múltiples plataformas.
4.8. Más allá de MVC
Los patrones de arquitectura como MVC y MVVM tienen su foco en aplicaciones donde principalmente tenemos interacciones de usuario (UX), pero muchas veces las aplicaciones deben comunicar con servicios externos y otros elementos que necesitan otras formas de gestionar la arquitectura de código.
Para esto se recomienda utilizar patrones como los definidos en el Diseño Orientado a Dominio (Domain Driven Design) y arquitectura Hexagonal.
5. Diseño de Sistemas (System Design)
El diseño del sistema es el proceso de diseñar la arquitectura, los componentes y las interfaces de un sistema para que cumpla con los requisitos del usuario final. Se refiere al proceso de definir la arquitectura, los módulos, las interfaces y los datos para que un sistema satisfaga requisitos específicos. Es un campo multidisciplinario que implica análisis de compensaciones, equilibrio de requisitos conflictivos y toma de decisiones sobre opciones de diseño que impactar el sistema en general.
En las últimas dos décadas, ha habido muchos avances en aplicaciones web a gran escala. Estos avances han redefinido la forma en que pensamos sobre el desarrollo de software. Todas las aplicaciones y servicios que usamos a diario, como Facebook, Instagram y Twitter. , son sistemas escalables. Miles de millones de personas en todo el mundo acceden a estos sistemas simultáneamente, por lo que deben diseñarse para manejar grandes cantidades de tráfico y datos. Aquí es donde entra en juego el diseño del sistema.
Como desarrollador de software, se espera cada vez más que comprenda los conceptos de diseño de sistemas y cómo aplicarlos. En las primeras etapas de su carrera, aprender diseño de sistemas le permitirá abordar problemas de diseño de software con más confianza y aplicar principios de diseño a sus proyectos.
El diseño de sistemas es un tema enorme. Cada uno tiene un enfoque diferente ya que no existen pautas paso a paso.
5.1. Estimación de Costos
Una estimación es un ejercicio de calcular los costos y requerimientos de un sistema de forma que se pueda tener una idea y referencia sobre el funcionamiento y costos futuros del mismo.
Estimar nos permite validar si la solución está dentro de los parámetros aceptables y analizar su factibilidad técnica y económica. La estimación es suficiente con que sea cercana al valor real, debido a que muchas variables pueden afectar los costos en el futuro.
Para poder estimar se necesitan algunas nociones y métricas básicas que pueden ser aplicadas a cualquier sistema.
5.1.1. Unidad de Volumen de Datos
El almacenamiento y transferencia de datos comunmente se mide en Bytes y potencias de 2, debido a que un caracter ASCII es 1 byte (8 bits).
La siguiente tabla muestra la unidad de volumen de datos.
Potencia | Valor Aproximado | Nombre | Abreviación |
---|---|---|---|
1 |
1 Uno (bit) |
Bit |
b |
8 |
8 Ocho (bits) |
Byte |
B |
10 |
1 Mil (bits) |
Kilobyte |
1 KB |
20 |
1 Millón (bits) |
Megabyte |
1 MB |
30 |
1 Mil Millón (bits) |
Gigabyte |
1 GB |
40 |
1 Billón (bits) |
Terabyte |
1 TB |
50 |
1 Cuatrillón (bits) |
Petabyte |
1 PB |
5.1.2. Tipos de Datos
Los tipos de datos que pueden ser usados en una base de datos tienen una cantidad de almacenamiento definido. Va a cambiar dependiendo del motor de base de datos usado. La siguiente tabla muestra un aproximado de los tipos de datos más comunes.
Tipo de Dato | Tamaño de Almacenamiento | Descripción |
---|---|---|
boolean (booleano) |
1 byte |
verdadero o falso. |
smallint (entero pequeño) |
2 bytes |
Un entero con valores acotados. |
integer (entero) |
4 bytes |
Un número entero tradicional. |
bigint (entero grande) |
8 bytes |
Un número entero con mayor capacidad. Para números aún más grandes. |
float (decimal) |
4 bytes |
Un número decimal con 6 decimales de precisión. |
double (decimal con doble precisión) |
8 bytes |
Un número decimal con 15 decimales de precisión. |
varchar (caracteres variable) |
(4 + n) byte |
Se suma la cantidad de caracteres más 4 para obtener el total de espacio requerido. |
blob (binario) |
variable |
Un archivo binario almacenado. El tamaño dependerá de cada archivo. |
5.1.3. Números de Latencia
La latencia nos indica cuánto se demora un proceso desde que se hace la petición hasta recibir una respuesta. A mayor cantidad de latencia, mayor será el tiempo que necesitemos esperar para obtener una respuesta. El tiempo de retraso de las latencias puede crear ineficiencias, especialmente en las operaciones en tiempo real.
Los siguientes gráficos contienen números aproximados, ya que según el avance tecnológico pueden variar con los años.
Basado en los números de Jeff Dean y Peter Norvig (http://norvig.com/21-days.html#answers).
Operation | ns | µs | ms | note |
---|---|---|---|---|
L1 cache reference |
0.5 ns |
|||
Branch mispredict |
5 ns |
|||
L2 cache reference |
7 ns |
14x L1 cache |
||
Mutex lock/unlock |
25 ns |
|||
Main memory reference |
100 ns |
20x L2 cache, 200x L1 cache |
||
Compress 1K bytes with Zippy |
3,000 ns |
3 µs |
||
Send 1K bytes over 1 Gbps network |
10,000 ns |
10 µs |
||
Read 4K randomly from SSD* |
150,000 ns |
150 µs |
~1GB/sec SSD |
|
Read 1 MB sequentially from memory |
250,000 ns |
250 µs |
||
Round trip within same datacenter |
500,000 ns |
500 µs |
||
Read 1 MB sequentially from SSD* |
1,000,000 ns |
1,000 µs |
1 ms |
~1GB/sec SSD, 4X memory |
Disk seek |
10,000,000 ns |
10,000 µs |
10 ms |
20x datacenter roundtrip |
Read 1 MB sequentially from disk |
20,000,000 ns |
20,000 µs |
20 ms |
80x memory, 20X SSD |
Send packet CA → Netherlands → CA |
150,000,000 ns |
150,000 µs |
150 ms |
-
1 ns = 10^-9 segundos
-
1 us = 10^-6 segundos = 1,000 ns
-
1 ms = 10^-3 segundos = 1,000 us = 1,000,000 ns
Cachés L1 y L2: 1 ns, 10 ns
Normalmente están integrados en el chip del microprocesador. A menos que trabaje directamente con hardware, probablemente no necesite preocuparse por ellos.
Acceso a RAM: 100 ns
Se necesitan alrededor de 100 ns para leer datos de la memoria. Redis es un almacén de datos en memoria, por lo que se necesitan unos 100 ns para leer datos de Redis.
Envía 1K bytes a través de una red de 1 Gbps: 10 us
Se necesitan alrededor de 10 usuarios para enviar 1 KB de datos desde Memcached a través de la red.
Leer desde SSD: 100 us
RocksDB es un almacén K/V basado en disco, por lo que la latencia de lectura es de alrededor de 100 us en SSD.
Operación de inserción de base de datos: 1 ms.
La confirmación de Postgresql puede tardar 1 ms. La base de datos necesita almacenar los datos, crear el índice y vaciar los registros. Todas estas acciones toman tiempo.
Enviar paquete CA→Países Bajos→CA: 100 ms
Si tenemos una llamada de larga distancia por Zoom, la latencia podría rondar los 100 ms.
Reintentar/actualizar interno: 1-10s
En un sistema de monitoreo, el intervalo de actualización generalmente se establece en 5 a 10 segundos (valor predeterminado en Grafana).
Resumen
Al leer los datos se puede concluir las siguientes cosas:
-
Leer de la memoria es más rápido que leer de un disco duro.
-
Leer del disco duro solo cuando sea obligatorio.
-
Los algoritmos de compresión son rápidos y se recomienda su utilización al enviar los datos por la red.
-
Los centros de datos de diferentes regiones requerirán más tiempo para transferir datos entre ellos.
5.1.4. Estimación General
El primer paso en el proceso de estimación es definir los objetivos.
-
Nivel mínimo: Objetivo que no tiene grandes exigencias. ¿Cuánto es lo mínimo que el sistema necesitaría para funcionar correctamente?.
-
Nivel promedio: Objetivo que busca definir el comportamiento normal de un sistema. ¿Cuánto es lo que necesitaría el sistema en un día normal?.
-
Nivel crítico: Objetivo que busca definir el comportamiento exigente de un sistema. ¿Cuánto es lo que necesitaría el sistema en un día de alta exigencia?.
Una vez definido el objetivo y los supuestos a cumplir, se debe transformar a datos como tamaño de almacenamiento o tamaño de transferencia. Ya que normalmente son los necesarios para comparar con la tabla de precios de un proveedor de servicios. Al tener el tamaño de almacenamiento o transferencia, se puede estimar los costos monetarios necesarios para lograr los objetivos planteados.
Cantidad de Usuarios Diarios (CUD)
La cantidad de usuarios diarios nos ayudará a definir cuán grande es el volumen de consultas por segundo de un sistema, teniendo en consideración las operaciones que los usuarios realicen.
Consultas por Segundo (QPS: Queries per Second)
Una métrica común es ¿Cúantas consultas tendrá por segundo la aplicación?. Esto nos permite determinar la cantidad de almacenamiento y datos necesarios en los casos hipotéticos acordados.
Ejemplo: Red Microblogging
Una red microblogging similar a sistemas como Mastodon o X (Twitter).
Objetivos y Supuestos
-
300 millones de usuarios activos mensuales.
-
50% utiliza el sistema diariamente.
-
Se realizan 2 posts por día en promedio.
-
10% de los posts contienen imagenes (media).
-
Los datos se almacenan por 5 años.
Obtención de las QPS (Querys per Second)
El primer paso es obtener la cantidad de usuarios diarios (CUD), para esto obtenemos el 50% de 300 millones.
-
300 millones (Usuarios Mensuales) * 50% (Uso diario) = 150 millones (Usuarios Diarios)
Sabemos que con 150 millones de usuarios diarios, cada usuario realiza 2 posts por día. Esto lo debemos transformar a segundos.
posts_por_dia = 150 millones usuarios * 2 posts
horas_por_dia = 24
segundos_por_dia = 3600
QPS = posts_por_dia / horas_por_dia / segundos_por_dia
QPS = ~3500 Queries por Segundo.
Ahora si tomamos la cantidad total de usuarios y asumiendo que todos los usuarios realizan dos posts en un mismo día
QPS_MAX = 2 * QPS = ~7000 Queries por Segundo.
Almacenamiento Estimado
Ahora si definimos que cada post contiene la siguiente información:
id varchar(64) -- cadena de caracteres de 64 bytes
text varchar(140) -- cadena de caracteres de 140 bytes
media blob(1MB) -- imagen de 1 MegaByte
Utilizando la QPS
podemos calcular cuánto espacio de almacenamiento necesitamos.
peso_imagen = 10% * 1 MB
posts_por_dia * peso_imagen
terabytes_por_dia = 30
terabytes_en_5_anios = terabytes_por_dia * 365 * 5 // 55 PetaBytes
5.2. Tipos de Configuración de Servidores
Los servidores pueden estar configurados de distinta forma dependiendo de las necesidades de la aplicación y las capacidades técnicas requeridas. En el ciclo de vida de la aplicación se puede dar situaciones en las que se deba aumentar los recursos disponibles y de que forma son distribuidos.
5.2.1. Servidor Único
Este es una configuración inicial. Todos los servicios de la aplicación (servidor web, base de datos, almacenamiento de archivos, etc). Están dentro de una sola máquina y comparten recursos de red, procesador, memoria y almacenamiento.
Ventajas
-
Es fácil de configurar.
-
Es relativamente barato.
-
Ideal para aplicaciones pequeñas y de poco alcance.
Desventajas
-
Propenso a errores por agotamiento de memoria o disco.
-
Solamente un servidor, si este es atacado o comprometido en seguridad, puede significar una brecha total o caida total del servicio.
-
Puede tener mayor latencia para usuarios lejos de la región donde está ubicado el servidor.
5.2.2. Servidor de Base de Datos Separado
El siguiente nivel en la configuración es separar el servidor de la base de datos, dandole una instancia propia del servidor de aplicaciones.
Ventajas
-
La base de datos tiene sus recursos separados del servidor de aplicaciones.
-
Permite escalar individualmente cada servidor según necesidades.
-
La seguridad es mayor al no compartir la misma máquina.
Desventajas
-
Aumenta los costos de mantenimiento al tener más máquinas funcionando.
5.2.3. Una Máquina por Servicio
Una vez que las necesidades de la aplicación lo requieran, se puede buscar la configuración a través de la separación de una máquina por servicio. Por ejemplo si la aplicación tiene: servidor web, base de datos, almacenamiento de archivos y procesamiento de datos. Se podría tener una máquina por cada elemento del sistema, una máquina para el servidor web, otra máquina para la base de datos, otra para el sistema de almacenamiento y otra para el procesamiento de datos.
Ventajas
-
Cada componente es separado y puede escalar individualmente.
Desventajas
-
Los costos aumentan considerablemente.
5.3. Escalado horizontal y vertical
La escalabilidad se refiere a la capacidad de una aplicación para manejar y soportar una mayor carga de trabajo sin sacrificar la latencia. Una aplicación necesita una potencia informática sólida para escalar bien. Los servidores deben ser lo suficientemente potentes para manejar mayores cargas de tráfico. Hay dos formas principales de escalar una aplicación: horizontalmente y verticalmente.
5.3.1. Escalado Horizontal
El escalamiento horizontal, o ampliación, significa agregar más hardware al conjunto de recursos de hardware existente. Aumenta la potencia computacional del sistema en su conjunto.
En el escalado horizontal, agrega más máquinas en paralelo para hacer frente a los requisitos crecientes. Necesitará equilibrio de carga para distribuir la carga en todo el sistema. Si alguna máquina falla, las solicitudes se redirigen a las otras máquinas y se escala bien cuando su Los usuarios aumentan y la inconsistencia de los datos es un inconveniente.
5.3.2. Escalado Vertical
El escalamiento vertical, o ampliación, significa agregar más potencia a su servidor. Aumenta la potencia de el hardware que ejecuta la aplicación. El escalado vertical utiliza una máquina enorme que maneja todas sus solicitudes y mejora el tiempo de respuesta y el rendimiento. Aunque ofrece llamadas de red más rápidas, coherencia de datos y sin equilibrio de carga, tiene un único punto de falla y limitaciones de hardware.
5.4. Balanceo de Carga (Load Balancer)
El balanceador de carga nos permite distribuir el tráfico de red entrante entre múltiples recursos, lo que garantiza una alta disponibilidad y confiabilidad al enviar solicitudes solo a los recursos que están en línea, lo que brinda la flexibilidad de agregar o restar recursos según lo requiera la demanda.
Los sitios web modernos con mucho tráfico deben atender cientos de miles, si no millones, de solicitudes simultáneas de usuarios o clientes. Para escalar de manera rentable y satisfacer estos grandes volúmenes, las mejores prácticas informáticas modernas generalmente requieren agregar más servidores.
Un balanceador de carga puede ubicarse frente a los servidores y enrutar las solicitudes de los clientes a través de todos los servidores capaces de satisfacer esas solicitudes de una manera que maximice la velocidad y la utilización de la capacidad. Esto garantiza que ningún servidor tenga exceso de trabajo, lo que podría degradar el rendimiento. se cae, el balanceador de carga redirige el tráfico a los servidores en línea restantes. Cuando se agrega un nuevo servidor al grupo de servidores, el balanceador de carga comienza automáticamente a enviarle solicitudes.
5.5. Redundancia y Replicación
La replicación es el proceso de compartir información para garantizar la coherencia entre recursos redundantes. Puede replicar componentes de software o hardware para mejorar la confiabilidad, la tolerancia a fallas o la accesibilidad. La replicación se utiliza en muchos sistemas de administración de bases de datos (DBMS), generalmente con una réplica primaria. La relación entre el original y sus copias. El servidor primario recibe todas las actualizaciones, y esas actualizaciones pasan a través de los servidores de réplica. Cada servidor de réplica genera un mensaje cuando recibe correctamente la actualización.
5.6. Base de datos Fragmentada (Database Sharding)
La fragmentación de bases de datos es una técnica para el escalado horizontal de bases de datos, donde los datos se dividen en múltiples instancias de bases de datos, o fragmentos, para mejorar el rendimiento y reducir el impacto de grandes cantidades de datos en una sola base de datos.
5.7. Colas de mensajes
Una cola de mensajes es una cola que enruta mensajes desde un origen a un destino, o desde el remitente al receptor. Sigue la política FIFO (primero en entrar, primero en salir). El mensaje que se envía primero se entrega primero. Las colas de mensajes facilitan la asincronía. Comportamiento, que permite que los módulos se comuniquen entre sí en segundo plano sin obstaculizar las tareas primarias. También facilitan la comunicación entre módulos y proporcionan almacenamiento temporal para los mensajes hasta que sean procesados y consumidos por el consumidor. Las más conocidas son Kafka o RabbitMQ.
5.8. Caché
El almacenamiento en caché es un concepto de diseño de sistema que implica almacenar datos a los que se accede con frecuencia en una ubicación a la que se puede acceder fácil y rápidamente. El propósito del almacenamiento en caché es mejorar el rendimiento y la eficiencia de un sistema al reducir la cantidad de tiempo que lleva acceder a los datos a los que se accede con frecuencia.
El almacenamiento en caché se puede utilizar en una variedad de sistemas diferentes, incluidas aplicaciones web, bases de datos y sistemas operativos. En cada caso, el almacenamiento en caché funciona almacenando datos a los que se accede con frecuencia en una ubicación más cercana al usuario o la aplicación. Esto puede incluir el almacenamiento datos en la memoria o en un disco duro local.
5.9. Lectura Complementaria
-
https://www.geeksforgeeks.org/caching-system-design-concept-for-beginners/
-
https://www.educative.io/blog/complete-guide-to-system-design
-
https://www.educative.io/courses/grokking-modern-system-design-interview-for-engineers-managers
-
https://www.educative.io/courses/web-application-software-architecture-101
-
https://www.geeksforgeeks.org/database-sharding-a-system-design-concept/
-
Libro System Design Interview [systemdesign].
6. Github, Static Site Generators, Markdown, Linux y Vim
GitHub es un servicio basado en la nube que aloja un sistema de control de versiones (VCS) llamado Git. Éste permite a los desarrolladores colaborar y realizar cambios en proyectos compartidos, a la vez que mantienen un seguimiento detallado de su progreso.
El control de versiones es un sistema que ayuda a rastrear y gestionar los cambios realizados en un archivo o conjunto de archivos. Utilizado principalmente por ingenieros de software para hacer un seguimiento de las modificaciones realizadas en el código fuente, el sistema de control de versiones les permite analizar todos los cambios y revertirlos sin repercusiones si se comete un error.
Git es un proyecto de código abierto que se inició en 2005 y creció hasta convertirse en uno de los VCS más populares del mercado: cerca del 87% de los desarrolladores utilizan Git para sus proyectos.
6.1. ¿Qué nos permite realizar?
-
Gestionar los proyectos con Github Projects.
-
Tener un acerbo documental con Github Wiki.
-
Tener un foro con Github Discussions.
-
Tener una página web estática con Github Pages.
-
Almacenar código y archivos con Github Repos.
-
Tener trazabilidad de las tareas con Github Issues.
-
Realizar acciones y flujos automatizados con Github Actions.
6.2. ¿Qué es un Fork (Bifurcación)?
Cuando nos gusta el repositorio de alguien y nos gustaría tenerlo en nuestra cuenta de GitHub, hacemos un fork o bifurcación para poder trabajar con él en forma separada.
Cuando hacemos un fork de un repositorio, obtenemos una instancia de todo el repositorio con todo su historial. Luego, podemos hacer lo que queramos sin afectar la versión original.
6.3. ¿Qué es un Pull Request?
Los pull requests son la forma de contribuir a un proyecto grupal o de código abierto.
Por ejemplo, un usuario llamado Juan realiza un fork de un repositorio de Luis y le efectúa algunos cambios. Ahora Juan puede hacer un pull request a Luis, pero dependerá de Luis aceptar o declinarlo. Es como decir: "Luis, ¿podrías por favor extraer (pull) mis cambios?".
En otros sistemas como Gitlab esta acción se le conoce como Merge Request.
6.3.1. Merge commits
Todos los commits de la rama se incorporarán al tronco principal.
6.3.2. Squash and merge
Todos los commits de la rama se fusionarán, solamente un commit con un mensaje nuevo será incorporado al tronco principal. Es la opción recomendada.
6.3.3. Rebase and merge
Reescribe el histórico de commits para incorporar los cambios de la rama. Usar con precaución.
6.4. Alternativas
6.5. Static Site Generators
Los static website generators son estructuras predefinidas de código sobre las que se pueden crear páginas web estáticas. A diferencia de los sistemas de gestión de contenidos, que recuperan el contenido de las bases de datos, los generadores de páginas estáticas (static site generators) crean los archivos HTML de una página a partir de un script basado en datos de entrada, que están almacenados en un sistema de archivos. Este proceso ya se lleva a cabo durante su desarrollo, mientras se realizan los cambios no solo en el código, sino también en el contenido. En otras palabras, este proceso no se efectúa cuando el usuario accede a la página web a través de su navegador.
La instalación y también el manejo de los static site generators se llevan a cabo por medio de la línea de comando. En cuanto al contenido de la página web, está escrito en lenguajes de marcado como, por ejemplo, Markdown. El generador, partiendo de los metadatos que aparecen en el inicio de los archivos, lo que se conoce generalmente como “front matter”, se encarga de que la página web se muestre en el navegador de los visitantes.
La diferencia principal entre el static site generator y el CMS se encuentra en el momento en que las páginas web se crean: el static website generator genera la página web durante el proceso de desarrollo, mientras que el CMS lo hace a petición del usuario. Además, el generador elimina la dependencia que existe en relación con las bases de datos u otra fuente de datos externa, así como el procesamiento de datos del lado del servidor al acceder a la página web. Por supuesto, también existe la posibilidad de integrar fuentes de datos externas con una Application Programming Interface (API).
6.6. Jekyll
Jekill es un generador de sitio estático con soporte incorporado para GitHub Pages. Jekyll toma los archivos Markdown y HTML y crea un sitio web estático completo en función de la opción de diseño.
6.7. Markdown y Asciidoc
Markdown es texto sin formato para escribir documentos estructurados, basado en convenciones para indicar el formato en correos electrónicos y publicaciones de Usenet. Fue desarrollado por John Gruber (con la ayuda de Aaron Swartz) y lanzado en 2004 en forma de una descripción de sintaxis y un script Perl (Markdown.pl) para convertir Markdown a HTML. En la próxima década, se desarrollaron docenas de implementaciones en muchos idiomas. Algunos ampliaron la sintaxis original de Markdown con convenciones para notas al pie, tablas y otros elementos del documento. Algunos permitieron que los documentos de Markdown se representaran en formatos distintos de HTML. Sitios web como Reddit, StackOverflow y GitHub tenían millones de personas que usaban Markdown. Y Markdown comenzó a usarse más allá de la web, para escribir libros, artículos, presentaciones de diapositivas, cartas y notas de conferencias.
Lo que distingue a Markdown de muchas otras sintaxis de marcado ligeras, que suelen ser más fáciles de escribir, es su legibilidad.
Markdown también es usado en algunos lenguajes de programación para generar documentación del código.
Ejemplo de Sintaxis
Encabezados
# H1
## H2
### H3
Listas
- Item 1
- Item 2
- Item 3
Enlaces
[Enlace](https://ninjas.cl)
![Imagen](https://ninjas.cl/imagen.jpg)
**Negrita**
_Cursiva_
Tablas
|Nombre|Descripción|
|------|-----------|
|Item 1| Ejemplo 1 |
|Item 2| Ejemplo 2 |
Código
```elixir
IO.inspect "Hola Mundo"
```
6.7.1. Complementos
6.7.2. Asciidoc
AsciiDoc es un lenguaje de marcado ligero y semántico diseñado principalmente para escribir documentación técnica. El lenguaje se puede usar para producir una variedad de formatos de salida ricos en presentaciones, todos a partir de contenido codificado en un formato de texto sin formato, conciso y legible por humanos.
El lenguaje AsciiDoc no está acoplado al formato de salida que produce. Un procesador AsciiDoc puede analizar y comprender un documento fuente AsciiDoc y convertir la estructura del documento analizado en uno o más formatos de salida, como HTML, PDF, EPUB3, página manual o DocBook. La capacidad de producir múltiples formatos de salida es una de las principales ventajas de AsciiDoc. Esta capacidad permite su uso en generadores de sitios estáticos, IDE, herramientas y servicios git, sistemas CI/CD y otro software.
AsciiDoc cierra la brecha entre la facilidad de escritura y los rigurosos requisitos de creación técnica y publicación. AsciiDoc solo requiere un editor de texto para leer o escribir, por lo que ofrece una barra baja para comenzar.
Ejemplo de Sintaxis
Encabezados
= H1
== H2
==== H3
Listas
- Item 1
- Item 2
- Item 3
Enlaces
https://ninjas.cl[Enlace]
image:https://ninjas.cl/imagen.jpg[Imagen]
*Negrita*
_Cursiva_
Tablas
|====
|Nombre|Descripción|
|Item 1| Ejemplo 1 |
|Item 2| Ejemplo 2 |
|====
Código
[source,elixir]
IO.inspect "Hola Mundo"
6.7.3. Mermaid
Mermaid te permite crear diagramas y visualizaciones usando texto y código.
Es una herramienta de creación de diagramas y gráficos basada en JavaScript que genera definiciones de texto inspiradas en Markdown para crear y modificar diagramas dinámicamente.
Si estás familiarizado con Markdown, no debería tener problemas para aprender la sintaxis de Mermaid.
flowchart TD A1(Historia de la Web) --> |Unidad 1| B1 B1(Hosting y Servidores) --> B2[Conceptos de Servidores] B1 --> B3[Cpanel] B1 --> B4[Sistemas CMS y Static Site Generators] B1 --> B5[HTML, CSS, Markdown] B1 --> B6[Github y Git]
Enlaces
6.7.4. DBML
DBML (Lenguaje de marcado de bases de datos) es un lenguaje DSL de código abierto diseñado para definir y documentar esquemas y estructuras de bases de datos.
También viene con una herramienta de línea de comandos y un módulo de código abierto para ayudarlo a convertir entre DBML y SQL.
Table users {
id integer
username varchar
role varchar
created_at timestamp
}
Table posts {
id integer [primary key]
title varchar
body text [note: 'Content of the post']
user_id integer
status post_status
created_at timestamp
}
Enlaces
6.8. GNU/Linux
GNU/Linux es hoy por hoy el Sistema Operativo preferido por el mundo de la informática y en general por el mundo corporativo en cuanto a servidores se refiere, y es preferido de manera muy especial en la nube. La confianza depositada en él se refuerza día a día gracias a los casos de éxito y millones de aplicaciones, presencia en servidores de todo tipo en infraestructuras locales, en la nube y dispositivos que corren Linux.
He aquí algunos números impresionantes que confirman que Linux es el amo y señor en todas las infraestructuras de servidores a nivel mundial, incluyendo la nube:
-
El 100% de las 500 supercomputadoras más poderosas en el mundo corren Linux.
-
23 de cada 25 páginas activas de Internet corren Linux, la mayoría de estas están hospedadas en la nube.
-
El 96% de los servidores más poderosos del mundo corren Linux, la mayoría de estos están hospedados en la nube.
-
El 90% de los servidores en los mayores proveedores de servicios de nube son Linux.
6.8.1. LPIC-1
Dado su extenso uso, recomendamos aprender a utilizarlo y certificar los conocimientos con LPIC-1. La certificación Linux más grande y reconocida del mundo. LPIC-1 es la primera certificación en el programa de certificación profesional Linux multinivel del Linux Professional Institute (LPI). El LPIC-1 validará la capacidad del candidato para realizar tareas de mantenimiento en la línea de comando, instalar y configurar una computadora con Linux y configurar redes básicas.
Enlaces
6.8.2. RedHat, CentOS, Rocky y Alma Linux
Distribuido por Red Hat y ahora parte de IBM, Red Hat o Red Hat Enterprise Linux (RHEL por sus siglas en inglés), como es oficialmente conocido, es una distro sumamente estable, la preferida por la mayoría de las empresas que se dedican a distribuir bases de datos, plataformas de software complejas y demandantes. Las distribuciones basadas en RedHat son las recomendables para entornos con Cpanel. Una excelente alternativa gratuita es Rocky Linux.
6.8.3. Debian
El proyecto Debian fue fundado en 1993 por Ian Murdock. Él escribió el manifiesto de Debian, que utilizó como base para la creación de la distribución Linux Debian. Dentro de este texto, los puntos destacables son: mantener la distribución de manera abierta, coherente al espíritu del núcleo Linux y de GNU.
Es la distribución recomendada para uso tanto en servidores como escritorio personal.
6.8.5. FreeBSD/OpenBSD
FreeBSD y OpenBSD son dos distribuciones y alternativas muy buenas para Linux. La especialidad son servidores, firewalls y otros equipos de red.
6.8.6. Distrowatch
Noticias sobre las distintas distribuciones de Linux pueden ser encontradas en el sitio https://distrowatch.com/
6.8.7. FLISoL
El FLISoL es el evento de difusión de Software Libre más grande en Latinoamérica y está dirigido a todo tipo de público: estudiantes, académicos, empresarios, trabajadores, funcionarios públicos, entusiastas y aun personas que no poseen mucho conocimiento informático.
6.8.8. Servidores Virtualizados
Lo mejor es experimentar en un entorno que no cause problemas antes de comenzar en serio en un entorno real. Por tanto lo mejor es hacer una instalación virtual.
Ahora existen programas excelentes de virtualización. Se recomienda los que van a continuación porque son fáciles de usar y son una excelente plataforma para hacer pruebas.
-
Virtualbox: es un sofware de código abierto que puede ser usado libremente y tiene una lista impresionante de posibilidades.
-
VMWare: dispone de programas gratuitos de virtualización como VMWare Server y VMWare Player, que pueden ser utilizados de forma libre y gratuita.
-
Docker: Docker proporciona un conjunto de herramientas de desarrollo, servicios, contenido de confianza y automatizaciones, que se utilizan individualmente o en conjunto, para acelerar la entrega de aplicaciones seguras.
6.8.9. Comandos Básicos
pwd
Muestra la ruta del directorio actual.
$ pwd
/Users/ninjas
ls
Muestra los archivos y directorios de la ruta especificada. Predeterminado la ruta actual.
-
El parámetro
-a
nos permite mostrar archivos ocultos (comienzan por punto). -
El parámetro
-l
nos permite mostrar los permisos, grupos, propietarios y fechas de modificación de archivos y directorios.
$ ls -la
ls -la
total 0
drwxr-xr-x 2 ninjas staff 64 Aug 22 21:03 .
drwxr-xr-x+ 140 ninjas staff 4480 Aug 22 21:05 ..
-
ls -la directorio
: Muestra los contenidos del directorio -
ls -R
: Muestra los contenidos de forma recursiva.
mkdir
Crea un directorio.
$ mkdir mi_directorio
-
mkdir -p primer/segundo
: Crea tanto el directorioprimer
como el directoriosegundo
.
touch
Crea un archivo en blanco.
Nota: A diferencia de Windows, los archivos en UNIX no necesitan extensión para ser válidos.
$ touch archivo
rm
Elimina un archivo o directorio.
-
El parámetro
r
indica recursivo. Necesario para eliminar todos los archivos de un directorio. -
El parámetro
f
indica "forzar". No preguntará antes de eliminar un archivo.
$ rm -rf mi_directorio
mv
Mueve un directorio o archivo. Utilizado también para renombrar archivos o directorios.
El siguiente ejemplo renombra el directorio1 a directorio2.
$ mv directorio1 directorio2
cp
Copia un archivo o directorio.
$ cp archivo1 archivo2
$ cp -R directorio1 directorio2
cat
Muestra los contenidos de un archivo.
$ cat archivo
cd
Cambiar el directorio actual.
-
.
Directorio actual -
..
Directorio anterior
Ir a directorio1
$ cd directorio1
Volver al directorio anterior
$ cd ..
Ir al directorio sub anterior.
$ cd ../../
pipe (|
)
El pipe es una herramienta especial que nos permite concatenar la salida del comando anterior con la entrada del siguiente comando.
-
Comando-1 | Comando-2 | …| Comando-N
$ cat contents.txt | grep file
0 Aug 9 13:55 file1
0 Aug 9 13:55 file2
0 Aug 9 13:55 file3
0 Aug 9 13:55 file4
0 Aug 9 13:55 file5
Enlaces
Permisos
Los permisos nos indican quien tiene autorización de ejecución, lectura y escritura de archivos y carpetas. Es un tema extenso pero en general se recomienda tener los siguientes permisos:
-
777
: Peligro, este permiso da acceso total de ejecución, modificación y lectura de forma global. -
755
: Recomendado para directorios. -
644
: Recomendado para archivos.
Enlaces
6.8.10. Tutoriales
6.9. Editor Vim
Vi ha sido el primer editor de texto a pantalla completa para sistemas Unix . Además fue creado con la intención de que fuese sencillo en su uso y ligero para no cargar sobremanera el sistema. Para aquellos acostumbrados a usar editores de texto mediante en entornos gráficos, puede resultar un poco abrupto y complejo su aprendizaje, pero si bien porque estamos al cargo de un servidor Linux o porque nuestro entorno gráfico está dando problemas y no carga, deberíamos ser capaces de editar ficheros desde un editor como Vi / Vim.
6.9.1. Modo Comando
El Modo Comando permite al usuario navegar por el documento así como introducir comandos a ejecutar dentro del propio archivo (buscar, reemplazar, guardar…), ya que en este modo el programa no interpreta las teclas del teclado por los caracteres que representan, si no por las funciones preestablecidas o comandos asignados a cada tecla.
Estos escuetos comandos son combinaciones de letras sensibles a mayúsculas (que corresponden a diferentes órdenes). A algunos de estos comandos podemos introducir un número delante que indicará el número de veces que queremos repetir la acción a ejecutar.
Por poner un ejemplo, si el comando yy
(o Y ) copia la línea donde se encuentra el cursor, el comando 3yy
(o 3Y ) copiará la línea actual y las dos siguientes, sumando un total de 3 líneas.
Para entrar al modo comando únicamente deberemos pulsar Esc
en nuestro teclado.
Ejemplos
-
0
: Ir al principio de la línea. -
$
: Ir al final de la línea. -
gg
: Ir al principio del archivo. -
G
: Ir al final del archivo. -
i
: Pasar al Modo Inserción. -
o
: Modo inserción en línea siguiente. -
O
: Modo inserción en línea anterior. -
a
: Modo inserción en siguiente caracter. -
A
: Modo inserción al final de línea. -
dd
: Cortar la línea actual. -
3dd
: Cortar 3 líneas. -
dG
: Cortar todo el documento. -
u
: Deshacer cambios. -
yy
: Copiar la línea actual. -
p
: Pegar el contenido del portapapeles.
6.9.2. Modo ex
En el Modo ex
manipularemos los archivos.
Para entrar a este modo deberemos escribir :
(dos puntos)
seguido directamente por el nombre del comando ‘ex’ que queramos usar. Tras esto, vi volverá automáticamente al modo comando.
Ejemplos
-
:0
: Ir al principio del archivo. -
:$
: Ir al final del archivo. -
:w
: Guarda los cambios (require que el archivo tenga nombre). -
:w archivo
: Guarda el archivo actual comoarchivo
. -
:q!
: Salir sin guardar cambios. -
:x
: Guardar cambios y salir. -
:<número de línea>
: Ejemplo:2
. Ir al número de línea específico.
6.9.3. Modo Inserción
En el Modo inserción simplemente añadiremos texto al fichero. Mientras estemos en este modo, podremos
salir al modo comando directamente pulsando Esc
.
Existen otros modos para Vi / Vim como ‘visual’, ‘selección’, etc. Pero Comando, Ex e Inserción son los más comunes.
Enlaces
6.9.4. Configuraciones
6.9.5. Tutoriales
7. Hosting, Dominios y Cpanel
Registrar un dominio en Internet es el primer paso para tener presencia en la web. Sin embargo, con solo un dominio no podrás publicar tu sitio web, ya que también necesitarás un web hosting.
Es importante recalcar que con la elección y registro de tu dominio en Internet podrás crear cuentas de correos personalizados que te permitirán proyectar profesionalismo y ganarte la confianza de los clientes potenciales.
Otro de los puntos importantes de los dominios en Internet es que son términos memorizables y fáciles de recordar por los internautas, porque ¿no te parece que es más sencillo recordar google.com que su dirección IP 172.217.10.110?. Recuerda que será mucho más sencillo encontrarte si eliges un dominio que va acorde a lo que ofreces o quién eres.
Elegir la extensión de dominio va a depender de tus objetivos, ya que si tienes planificado un mercado global lo mejor para ti es elegir un dominio genérico.
Ahora bien, si tu mercado es nacional, lo más conveniente que uses un dominio geográfico porque ¡sí! tu página web se posicionará mucho mejor en ese país, debido a que Google — u otro buscador — lo considerará como un dominio casi exclusivo para esa región.
7.1. ¿Qué es una URI?
Una URI o identificador uniforme de recursos es una cadena de caracteres que generalmente identifica cualquier recurso web mediante un nombre, una ubicación o ambos. Un localizador uniforme de recursos (URL) y un nombre uniforme de recursos (URN) son los dos tipos de URI.
-
esquema:[//autoridad]ruta[?query][#fragmento]
Ejemplos:
-
ftp://ftp.is.co.za/rfc/rfc1808.txt
-
http://www.ietf.org/rfc/rfc2396.txt
-
ldap://[2001:db8::7]/c=GB?objectClass?one
-
mailto:John.Doe@example.com
-
news:comp.infosystems.www.servers.unix
-
tel:+1-816-555-1212
-
telnet://192.0.2.16:80/
-
urn:oasis:names:specification:docbook:dtd:xml:4.1.2
7.2. ¿Qué es una URL?
Una URL o localizador universal de recursos, por su siglas en inglés, es una dirección completa de un sitio web que lleva a los usuarios a una página específica dentro de ese website.
En síntesis, se trata de la dirección web que tiene cada uno de los recursos en Internet que les permite ser encontrados por los navegadores e identificados por diferentes herramientas.
Cada elemento que hace parte del WWW, sin importar su formato o propósito, debe tener una dirección URL específica donde está guardada.
En cuanto al puerto, es el número específico que identifica qué servicio web estás solicitando en un servidor web. Por ejemplo, el número de puerto predeterminado para la URL HTTP es 80 y para la URL HTTPS es 443. Sin embargo, si el servidor web utiliza un protocolo estándar como HTTP o HTTPS, el puerto suele omitirse en la URL.
7.2.1. ¿Por qué no es lo mismo que un dominio?
Básicamente, una URL está compuesta de un protocolo, el dominio y la ruta. Donde el protocolo garantiza la certificación de seguridad SSL, el dominio es la dirección y la ruta es la dirección de la página específica dentro del sitio web.
Entonces, es válido afirmar que los dominios para páginas web solo es una parte de los caracteres con los que está hecha un URL.
7.2.2. URL absolutas vs URL relativas
Las partes requeridas de una URL dependen en gran medida del contexto en el que se utiliza la URL. En la barra de direcciones de su navegador, una URL no tiene ningún contexto, por lo que debe proporcionar una URL completa (o absoluta), como las que vimos anteriormente. No necesita incluir el protocolo (el navegador usa HTTP de manera predeterminada) o el puerto (que solo se requiere cuando el servidor web de destino está utilizando algún puerto inusual), pero todas las otras partes de la URL son necesarias.
Cuando se usa una URL dentro de un documento, como en una página HTML, las cosas son un poco diferentes. Debido a que el navegador ya tiene la propia URL del documento, puede usar esta información para completar las partes faltantes de cualquier URL disponible dentro de ese documento. Podemos diferenciar entre una URL absoluta y una URL relativa mirando solo la parte de ruta de la URL. Si la parte de ruta de la URL comienza con el carácter "/", el navegador buscará ese recurso desde la raíz superior del servidor, sin referencia al contexto dado por el documento actual.
El uso de URLs relativas puede ser un riesgo para el robo de contenido ya que la gente no tiene que reescribir ningún enlace interno. Pueden copiar fácilmente tu página y ponerla en un nuevo dominio utilizando un raspador web (web scrapper).
URL | Descripción |
---|---|
|
URL Completa (absoluta) |
|
URL relativa con protocolo implícito (Reutiliza el protocolo inicial) |
|
URL relativa con dominio implícito |
|
URL relativa que utiliza el directorio actual. |
|
URL relativa que utiliza el directorio anterior. |
7.3. URL vs URI vs URN
Aunque en algunos casos un identificador uniforme de recursos (URI) y un localizador de recursos uniforme (URL) pueden utilizarse indistintamente, no son lo mismo.
URI significa identificador de recursos uniforme, una cadena de caracteres que generalmente identifica un recurso por un nombre, una ubicación o ambos en Internet. Además, un URI puede diferenciar tipos de archivos y otros recursos.
Por otro lado, una URL o localizador de recursos uniforme es una cadena de caracteres que muestra la dirección del recurso y cómo acceder a él en la página web. Como la URL es una parte de la URI, siguen una estructura similar.
En resumen, la principal diferencia entre una URI y una URL es que la primera puede ser un nombre, una ubicación o ambos, mientras que la segunda sólo proporciona la ubicación de un recurso.
A diferencia de una URL, una URN no proporciona ninguna información sobre la ubicación del recurso, sino que simplemente lo identifica, al igual que una URI pura. En particular, una URN es una URI cuyo esquema es urn y tiene la siguiente estructura, tal como lo describe el RFC 2141:
urn:<IDENTIFICADOR DEL ESPACIO DE NOMBRES>:<CADENA ESPECÍFICA DEL ESPACIO DE NOMBRES>
El marcador de posición IDENTIFICADOR DE ESPACIO DE NOMBRES>
representa una cadena que representa la categoría de recursos que desea identificar. <NAMESPACE-SPECIFIC-STRING>
es el identificador específico del recurso y su formato depende del identificador del espacio de nombres.
urn:isbn:1234567890
urn:ISSN:0167-6423
urn:ietf:rfc:2648
Esos URN identifican objetos de diferentes tipos. Por ejemplo, urn:isbn:1234567890
identifica una publicación a través del sistema ISBN; urn:ISSN:0167-6423
identifica una publicación a través del sistema ISSN; urn:ietf:rfc:2648
es un RFC emitido por el IETF.
7.4. ¿Qué tipos de Dominios Existen?
Hay tres tipos --o extensiones — de dominios que puedes utilizar para tu empresa y dependerá de lo que más adecuado para tu organización.
7.4.1. Dominios Geográficos
También llamados territoriales o ccTLD (Country code Top-Level Domain).
Este dominio es conformado por dos letras que van asociadas con el país de origen del sitio web. Estos se usan para señalar la ubicación de la empresa. Algunos ejemplos de dominios geográficos son:
-
.cl
, para Chile -
.ar
, para Argentina; -
.br
, para Brasil; -
.co
, para Colombia; -
.mx
, para México; -
entre otros.
7.4.2. Dominio de Nivel Superior Genéricos
También conocido como gTLD (Generic Top-Level Domain)
Son los más utilizados y comunes a nivel mundial. Estos no se ajustan a un país determinado y definen cuál es el fin del sitio web. Ejemplo:
-
.com
, es un sitio web de uso comercial; -
.net
, su significado es red y se relaciona con empresas de servicios de Internet o también para asociar un dominio que ya existe con la terminación .com; -
.org
, organización sin fines de lucro, ONG o instituciones; -
.edu
, se usa para instituciones de educación; -
.info
, sitio informativo; -
.biz
, página de negocios; -
.gob
, reservados exclusivamente para departamentos y entidades gubernamentales; -
.mil
, su uso es únicamente para entidades que pertenecen a las Fuerzas Armadas de un país; -
entre otros.
7.4.3. Dominios mixtos o de tercer nivel
Los dominios de tercer nivel son aquellos que resultan tras combinar un dominio gTLD y uno ccTLD.
En otras palabras, tienen la misma finalidad que los dominios genéricos, pero se limitan territoralmente. Entonces, sería:
-
.com.mx
, para entidades comerciales mexicanas; -
.org.mx
, referente a organizaciones no lucrativas mexicanas; -
.edu.mx
, consta de instituciones educativas mexicanas; -
.gob.mx
, entidades del Gobierno de México.
7.5. Estructura de un Dominio
Su estructura consta de dos niveles. Sin embargo, en el inicio existe un dominio raíz, que es solo un nombre vacío del que salen los demás dominios de Internet. Ahora bien, ¿en qué consisten?
7.5.1. Primer nivel
Del dominio raíz sale este primer nivel. Estos pueden ser: .cl
, .com
, .mx
, .org
, entre otros.
7.5.2. Segundo nivel
Es el nombre que se eligió para el dominio. En nuestro caso es: ninjascl
.
Subdominio
Es un derivado del dominio de segundo nivel, que se crea añadiendo una o varias palabras separada(s) por un punto. El www
. es el subdominio más común.
Sin embargo, también se puede agregar otros para permitir el acceso directo a una determinada sección de la página web.
Te recomendamos que para crear subdominios uses nombres cortos y palabras claves que tengan relación con el contenido que quieras mostrar.
7.6. ¿Dónde Compro un Dominio?
URL | Descripción |
---|---|
Compra de dominios en Chile. Valor promedio $10.000 CLP por año. |
|
Compra de dominios Internacional. Valor depende del TLD. Aceptan Paypal o tarjetas de crédito internacional como https://www.tenpo.cl/ o https://dalecoopeuch.cl/ |
|
Subdominios gratuitos. Ideal para tener servidores hogareños sin recurrir a un dominio principal. |
|
Subdominios gratuitos. Ideal para tener servidores hogareños sin recurrir a un dominio principal. |
7.7. ¿Qué es un Domain Name Server?
El sistema DNS (Domain Name Server) es el sistema más importante para el funcionamiento de internet. Sin DNS’s no funcionarían los nombres de dominios que utilizamos comúnmente.
Cada computadora conectada a internet tiene una dirección “lógica” única, algo así como un número telefónico, a la que llamamos dirección IP. Las direcciones IP que se utilizan actualmente (versión 4) constan de cuatro secciones numéricas separadas por un punto. Una dirección IP típica luciría así: 151.120.134.89 (esto es solo un ejemplo).
En términos prácticos, el sistema DNS es el que nos permite traducir “www.google.com” o cualquier otro dominio textual, a su equivalente numérico.
7.8. Ruta de un DNS
Cuando una persona escribe una dirección web en la barra de direcciones de su navegador, la computadora irá a buscar jerárquicamente por la traducción de dicha dirección en una dirección IP. Se dice jerárquicamente, ya que normalmente se comienza la búsqueda primero en los DNS’s raíz de internet (que son unos servidores que mantienen largas tablas de enrutamiento que hacen funcionar el corazón de este sistema) y una vez que haya encontrado el mapeo correcto la máquina irá a buscar la dirección concreta del equipo o “host” a los servidores DNS ligados al dominio en particular que estamos buscando.
Es por esta razón que cuando una persona va a “dirigir” su dominio a un servidor nuevo, se le pide que ingrese los servidores DNS que harán la función de direccionadores. Un ejemplo de esto es el siguiente:
-
Contratamos el dominio “ejemplo.com” con un proveedor de registro de dominios
-
Deseamos que “ejemplo.com” lleve directamente a nuestra página web que está localizada en la dirección IP 192.185.124.130
-
Nuestro proveedor del servicio de Hospedaje Web dará de alta el dominio en el servidor.
-
Nuestro proveedor del servicio de Hospedaje Web dará de alta el dominio en los servidores DNS que sean necesarios y nos proporcionará la dirección URL de estos servidores (al menos del servidor DNS primario y secundario, por ejemplo: ns1.ejemplo.com y ns2.ejempo.com)
-
Agregamos los servidores DNS primario y secundario a nuestro dominio directamente con nuestro proveedor de registro de dominios (ya sea por medio de algún panel de control o solicitándolo de otra forma)
En este ejemplo, hicimos lo siguiente:
1.- Registramos un nombre de dominio
2.- Dimos de alta el dominio en un servidor
3.- Dirigimos el dominio al servidor por medio de los servidores DNS primario y secundario.
7.9. ¿Por qué tardan los cambios de servidores DNS en propagar?
Otra situación sumamente común es que cuando cambiamos el direccionamiento de un dominio de unos servidores DNS a otros, nuestro proveedor nos indica que la “propagación” puede tardar 24 a 72 horas (normalmente es mucho menos). ¿Esto qué significa?
Lo que sucede es que para no sobrecargar los servidores raíz de internet y disminuir el tráfico por consultas de “traducciones” DNS de nombres de dominio a direcciones IP, el sistema de DNS funciona de tal forma que se guardan registros temporales de ciertas traducciones populares, por ejemplo: si uno hace una consulta para buscar ninjas.cl
, el sistema DNS de nuestro proveedor de acceso a internet nos devolverá la IP resultante de dicha consulta. Para hacer esa traducción muy probablemente tuvimos que consultar directamente a un servidor raíz de internet, sin embargo, si nosotros mismos volvemos a buscar esa dirección (o alguien que esté en la misma red o “vecindario” la busca) muy probablemente la traducción ya se encuentre guardada temporalmente en un servidor DNS de nuestro proveedor de acceso a internet, con lo que éste se ahorra el tener que ir a buscar dicha traducción directamente a los servidores raíz de internet.
El aspecto negativo de esto (por así llamarlo), es que si cambiamos en este momento el mapeo dominio/IP de ninjas.cl
, mucha gente en el mundo que esté accediendo a nuestra página web tendrá un periodo de tiempo de algunas horas en las que probablemente accederá aún a la dirección IP anterior que estará guardada en los servidores DNS de su proveedor de acceso a internet (el término correcto es que tiene el mapeo guardado en “caché”). Este mapeo, ahora incorrecto, se corregirá automáticamente cuando el cambio se “propague” hasta los servidores DNS de dicho proveedor de acceso a internet, lo cual por el tamaño de internet puede tardar varias horas.
7.10. Servidores y Hostings
Entre los hosting web existen principalmente las siguientes opciones:
-
Shared Hosting: Hosting Compartido. Un servidor con Cpanel (o Plesk) en el cual los recursos de la máquina (IP, RAM, CPU, Disco, etc) son compartidos por múltiples usuarios. Ideal para opciones económicas y menos exigencia.
-
Dedicated Hosting: (Hosting Dedicado). Un servidor con Cpanel en el cual los recursos de la máquina (IP, RAM, CPU, Disco, etc) son asignados a un solo usuario. Ideal para opciones que requieran mayor velocidad y recursos.
-
VPS (Virtual Private Server): Servidor Privado Virtual . Un servidor dedicado en el cual se debe instalar todo de forma manual (no tiene Cpanel u otros similares). Ideal para aplicaciones personalizadas (Como Backend) en lenguajes de programación distintos a PHP o que requieran recursos personalizados, más flexibles y que puedan adaptarse a las necesidades de crecimiento de la aplicación.
-
Hosting HTML Estático: Hosting especializado en páginas web estáticas. Solamente permite archivos con lógica en el cliente como HTML, CSS, JS y archivos (imágenes, documentos). No permite lenguajes como PHP, Elixir o Python. Se pueden mencionar neocities y github pages entre los más conocidos.
-
Servidor de Aplicaciones en la Nube: Servidor especializado en tener un ambiente preparado para algunos frameworks de backend, a diferencia de los VPS ya viene con algunas configuraciones y herramientas de apoyo. Alguno de los más conocidos son Heroku.com o Fly.io.
7.10.1. ¿Dónde Consigo un Hosting?
URL | Descripción |
---|---|
Hosting económico gama baja/media para servidores en Chile. Valor promedio $10.000 CLP por año. Ideal para tener un servidor de correos propio de forma económica. Páginas webs simples o de poco tráfico. |
|
Hosting de gama media en Chile. Valor promedio $30.000 CLP por año. Ideal para páginas web más exigentes o múltiples dominios. |
|
Hosting de gama baja/media en servidores internacionales. |
|
Hosting gama baja/media internacional. Muchos resellers compran a Hostgator y revenden en Chile. Revisar siempre que las ips y nameservers sean de chile antes de seleccionar un hosting chileno. |
|
Hosting de gama baja/media internacional |
|
VPS |
|
VPS |
|
VPS |
|
Hosting gratuito de páginas web estáticas |
|
Entre sus servicios gratuitos hospeda páginas web estáticas |
|
Si se tiene un proyecto en Github se puede utilizar su hosting gratuito para web estáticas. Ideal para documentación de proyectos o experimentos |
|
Servidor de Aplicaciones en la Nube |
|
Servidor de Aplicaciones en la Nube. Recomendado para Elixir. |
|
Servidor de Aplicaciones en la Nube. Especializado en Frontend. |
|
Plataforma de Servicios en la Nube de Amazon. |
|
Plataforma de Servicios en la Nube de Microsoft. |
|
Plataforma de Servicios en la Nube de Google. |
7.10.2. Herramienta Whois
Al momento de querer adquirir un dominio se debe verificar que no esté previamente registrado. Podemos utilizar las búsquedas de un proveedor de dominios, pero nos arriesgamos a que nuestra búsqueda quede registrada y posiblemente alguien desee comprar nuestro dominio dejándonos en una posición difícil. La recomendación es siempre comprar un dominión lo más pronto posible, ya que se arriesga a perderlo y verse obligado a pagar copiosas sumas de dinero por adquirirlo.
Para asegurárnos que nuestra búsqueda de dominio sea protegida de posibles oportunistas, utilizamos la herramienta whois
.
Cuando accedemos a los detalles con whois, tendremos acceso a la información de contacto asociada con la persona o empresa que registró el nombre de dominio en la red, es por ello que al usar whois accedemos a detalles como:
-
El nombre y la información de contacto del registrante
-
La fecha de registro
-
El nombre y la información de contacto del registrador
-
Última actualización del registro
-
Fecha de expiración del registro
Es por esto que se debe elegir un proveedor de dominios que permita el ocultar información privada, para evitar ser víctima de spam por medio de la obtención de datos usando whois
.
Al usar el comando whois debemos tener en cuenta los siguientes términos:
-
Registry: hace referencia a la empresa que administra la lista donde se aloja un conjunto de nombres de dominio
-
Registrant: es el propietario legal del dominio
-
Registrar: hace uso de un registrador para realizar el registro
Resultado de Dominio Existente
$ whois ninjas.cl
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
refer: whois.nic.cl
domain: CL
organisation: NIC Chile (University of Chile)
address: Miraflores 222, Piso 14
address: Santiago RM 832-0198
address: Chile
contact: administrative
name: TLD Admin Contact
organisation: NIC Chile
organisation: University of Chile
address: Miraflores 222, Piso 14
address: Santiago RM 832-0198
address: Chile
phone: +56 22 940 7700
e-mail: admincl@nic.cl
contact: technical
name: TLD Technical Contact
organisation: NIC Chile
organisation: University of Chile
address: Miraflores 222, Piso 14
address: Santiago RM 832-0198
address: Chile
phone: +56 22 940 7700
e-mail: techcl@nic.cl
nserver: A.NIC.CL 190.124.27.10 2001:1398:121:0:190:124:27:10
nserver: B.NIC.CL 200.7.4.7 2001:1398:274:0:200:7:4:7
nserver: C.NIC.CL 200.16.112.16 2001:1398:275:0:200:16:112:16
nserver: CL-NS.ANYCAST.PCH.NET 2001:500:14:6030:ad:0:0:1 204.61.216.30
nserver: CL1-TLD.D-ZONE.CA 185.159.197.56 2620:10a:80aa:0:0:0:0:56
nserver: CL1.DNSNODE.NET 194.146.106.34 2001:67c:1010:8:0:0:0:53
nserver: CL2-TLD.D-ZONE.CA 185.159.198.56 2620:10a:80ab:0:0:0:0:56
ds-rdata: 21199 8 2 7d756dffab6d3cd9c786ff5c659954c22944faef9433eee26f1d84eb5370b394
whois: whois.nic.cl
status: ACTIVE
remarks: Registration information: http://www.nic.cl/
created: 1987-12-15
changed: 2021-05-28
source: IANA
# whois.nic.cl
%%
%% This is the NIC Chile Whois server (whois.nic.cl).
%%
%% Rights restricted by copyright.
%% See https://www.nic.cl/normativa/politica-publicacion-de-datos-cl.pdf
%%
Domain name: ninjas.cl
Registrant name: Camilo
Registrant organisation:
Registrar name: NIC Chile
Registrar URL: https://www.nic.cl
Creation date: 2023-07-26 16:12:11 CLST
Expiration date: 2024-07-26 16:12:11 CLST
Name server: ns1.cpanelhost.cl
Name server: ns2.cpanelhost.cl
%%
%% For communication with domain contacts please use website.
%% See https://www.nic.cl/registry/Whois.do?d=ninjas.cl
%%
Resultado de Dominio Inexistente
$ whois ninjas-fake.cl
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
refer: whois.nic.cl
domain: CL
organisation: NIC Chile (University of Chile)
address: Miraflores 222, Piso 14
address: Santiago RM 832-0198
address: Chile
contact: administrative
name: TLD Admin Contact
organisation: NIC Chile
organisation: University of Chile
address: Miraflores 222, Piso 14
address: Santiago RM 832-0198
address: Chile
phone: +56 22 940 7700
e-mail: admincl@nic.cl
contact: technical
name: TLD Technical Contact
organisation: NIC Chile
organisation: University of Chile
address: Miraflores 222, Piso 14
address: Santiago RM 832-0198
address: Chile
phone: +56 22 940 7700
e-mail: techcl@nic.cl
nserver: A.NIC.CL 190.124.27.10 2001:1398:121:0:190:124:27:10
nserver: B.NIC.CL 200.7.4.7 2001:1398:274:0:200:7:4:7
nserver: C.NIC.CL 200.16.112.16 2001:1398:275:0:200:16:112:16
nserver: CL-NS.ANYCAST.PCH.NET 2001:500:14:6030:ad:0:0:1 204.61.216.30
nserver: CL1-TLD.D-ZONE.CA 185.159.197.56 2620:10a:80aa:0:0:0:0:56
nserver: CL1.DNSNODE.NET 194.146.106.34 2001:67c:1010:8:0:0:0:53
nserver: CL2-TLD.D-ZONE.CA 185.159.198.56 2620:10a:80ab:0:0:0:0:56
ds-rdata: 21199 8 2 7d756dffab6d3cd9c786ff5c659954c22944faef9433eee26f1d84eb5370b394
whois: whois.nic.cl
status: ACTIVE
remarks: Registration information: http://www.nic.cl/
created: 1987-12-15
changed: 2021-05-28
source: IANA
# whois.nic.cl
%%
%% This is the NIC Chile Whois server (whois.nic.cl).
%%
%% Rights restricted by copyright.
%% See https://www.nic.cl/normativa/politica-publicacion-de-datos-cl.pdf
%%
ninjas-fake.cl: no entries found.
7.10.3. Herramienta Ping
Ping nos ayuda a verificar que un servidor este operativo y escuchando peticiones.
Respuesta Exitosa
$ ping ninjas.cl
PING ninjas.cl (190.107.177.35): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 190.107.177.35: icmp_seq=1 ttl=58 time=23.394 ms
64 bytes from 190.107.177.35: icmp_seq=2 ttl=58 time=28.447 ms
64 bytes from 190.107.177.35: icmp_seq=3 ttl=58 time=15.794 ms
64 bytes from 190.107.177.35: icmp_seq=4 ttl=58 time=22.296 ms
64 bytes from 190.107.177.35: icmp_seq=5 ttl=58 time=16.409 ms
64 bytes from 190.107.177.35: icmp_seq=6 ttl=58 time=14.523 ms
64 bytes from 190.107.177.35: icmp_seq=7 ttl=58 time=14.737 ms
64 bytes from 190.107.177.35: icmp_seq=8 ttl=58 time=20.764 ms
--- ninjas.cl ping statistics ---
9 packets transmitted, 8 packets received, 11.1% packet loss
round-trip min/avg/max/stddev = 14.523/19.545/28.447/4.682 ms
Respuesta de Servidor No Encontrado
$ ping ninjas-fake.cl
ping: cannot resolve ninjas-fake.cl: Unknown host
Respuesta de Servidor que No Responde
$ ping 127.0.0.2
PING 127.0.0.2 (127.0.0.2): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
--- 127.0.0.2 ping statistics ---
8 packets transmitted, 0 packets received, 100.0% packet loss
7.11. Cpanel
cPanel (acrónimo de control Panel o ‘Panel de control’) es un panel de control para administrar servidores de alojamiento web que proveen herramientas de automatización y una interfaz gráfica basada en páginas web. Es software de tipo propietario y se ha desarrollado para ser compatible con la mayoría de las distribuciones de Linux que usen RPM como gestor de paquetes.
Hoy en día, cPanel se ha convertido prácticamente un estándar en servicios de hosting web.
Tanto es así que se considera por muchos un criterio fundamental a la hora de elegir un hosting.
Su principal ventaja es que el usuario de un hosting web, muchas veces personas sin perfil técnico, dispone de una interfaz web sencilla que le permite administrar los servicios más importantes de su hosting, principalmente:
-
Administración de ficheros: principalmente para la instalación de aplicaciones PHP como ProcessWire, WordPress, Joomla o Prestashop.
-
Configuración de los dominios: necesaria para vincular el sitio web el correo electrónico al (los) dominio(s) que se quiere(n) utilizar.
-
Gestión de cuentas de correo: creación y mantenimiento de cuentas de correo electrónico con dominio propio.
-
Gestión de bases de datos MySQL: creación y mantenimiento de bases de bases de datos, principalmente porque las aplicaciones típicas usadas en un hosting como las arriba mencionadas suelen requerir una base de datos MySQL.
-
Gestión de los recursos: espacio en disco, consumo de ancho de banda mensual, etc.
cPanel entrega un gran nivel de control al usuario individual, mientras se mantiene la seguridad. Aunque el administrador de sistema puede desactivar cualquier característica para cada cliente en cualquier momento, el usuario puede usar cualquier elemento que se encuentre disponible.
-
SSH Access: tiene integrado un applet Java que permite una conexión directa con el servidor vía SSH. Se encuentra desactivado en la mayoría de los sitios debido a que es un riesgo para la seguridad del servidor.
-
Crontab: provee una interfaz para el manejo de las listas de tareas.
-
OpenPGP: soporte técnico.
-
CGI Scripts: autoinstala varios scripts para cualquier sitio web.
-
Permite evitar el acceso a direcciones IP específicas.
-
Se distingue, respecto a otros control Panel, por su facilidad para realizar respaldos completos o parciales (algunos proveedores de hospedaje no dan derechos para restaurar respaldos).
-
Tiene una apariencia flexible y fácil de entender, llamada Paper Lantern, también hay otra llamada Jupiter.
7.11.1. WHM
WHM, abreviatura de WebHost Manager, es una herramienta basada en la web que se utiliza para la administración del servidor. Hay al menos dos niveles de WHM, a menudo denominados "WHM raíz" y WHM no raíz (o WHM de revendedor). Root WHM es utilizado por administradores de servidores y WHM no root (con menos privilegios) es utilizado por otros, como departamentos de entidades y revendedores para administrar cuentas de alojamiento a menudo denominadas cuentas cPanel en un servidor web. WHM también se usa para administrar certificados SSL (tanto certificados SSL autogenerados por el servidor como proporcionados por CA), usuarios de cPanel, paquetes de alojamiento, zonas DNS, temas y métodos de autenticación. El SSL automático predeterminado (AutoSSL) proporcionado por cPanel es impulsado por Sectigo (anteriormente Comodo CA). Además, WHM también se puede usar para administrar servicios de FTP, correo (POP, IMAP y SMTP) y SSH en el servidor.
Además de ser accesible para el administrador raíz, WHM también es accesible para los usuarios con privilegios de revendedor. Los usuarios revendedores de cPanel tienen un conjunto de funciones más pequeño que el usuario raíz, generalmente limitado por el administrador del servidor, a funciones que determinan que afectarán las cuentas de sus clientes en lugar del servidor en su conjunto. Desde la raíz WHM, el administrador del servidor puede realizar operaciones de mantenimiento, como actualizar y volver a compilar Apache y PHP, instalar módulos Perl y actualizar los RPM instalados en el sistema.
Enlaces
7.11.2. Alternativas
Muchas veces Cpanel puede no ser la mejor opción, debido a su precio o sus restricciones tecnológicas. Para esto existen algunas alternativas a considerar:
-
Direct Admin (Pago)
-
Plesk (Pago)
-
Webmin (Gratis)
-
Froxlor (Gratis)
7.11.3. Certificados SSL
Son certificados que permiten a las aplicaciones comunicarse de forma segura. Por ejemplo al momento de enviar un formulario, si la página es solamente http
, toda la información enviada podría ser obtenida por un tercero no autorizado. Por esto siempre es importante utilizar certificados SSL (https
) al momento de crear sistemas web.
En los paneles Cpanel existe una opción llamada AutoSSL que genera certificados. Puede también ser utilizado https://letsencrypt.org/, una opción gratuita que no está ligada a Cpanel.
Enlaces
7.12. Lectura Complementaria
Siempre tener en cuenta que estos solo son paneles de administración en servidores (usualmente Linux), por lo que todas las operaciones que realizan estos paneles se pueden realizar mediante la terminal del sistema operativo.
Se recomienda mucho aprender Linux/FreeBSD y tomar la certificación respectiva para aprender administrar servidores.
8. Redes e Internet
SUBTEL (Subsecretaría de Telecomunicaciones): es un organismo dependiente del Ministerio de Transportes y Telecomunicaciones. Su trabajo está orientado a coordinar, promover, fomentar y desarrollar las telecomunicaciones en Chile, transformando a este sector en motor para el desarrollo económico y social del país.
8.1. ISP: Internet Service Provider
Existen diversas formas de clasificar a los ISP, sin embargo, la tipificación comúnmente utilizada es “TIER”, la cual se relaciona directamente con la cobertura geográfica que abarca. El número de TIER que se le asigna a cada operador depende de la importancia en cobertura que presente en la red, comenzando con los operadores TIER 1 (aquellos de mayor cobertura) y descendiendo a medida que pierden relevancia en el ecosistema IP. Una tipificación alternativa clasifica a los ISP de acuerdo a la cantidad de redes IP que transporta. Independientemente de la clasificación, los operadores que ofrecen servicio de conectividad a otros ISP, típicamente se les denomina como Carriers, Mayoristas o Wholesale. A continuación, se detalla la clasificación considerando cada tipificación posible.
8.1.1. Tier 1
Son las redes de los grandes operadores globales (Global Carriers) que tienen tendidos de fibra óptica que abarcan al menos dos continentes. Desde una red TIER 1 se puede acceder a cualquier punto de Internet gracias a que es una condición necesaria para su clasificación que todos los operadores TIER 1 deben estar conectados entre sí. Se puede decir que las redes TIER 1 forman el actual “Backbone” o troncal de Internet. Algunos ejemplos de compañías que poseen redes TIER 1 son: AT&T (Estados Unidos), Orange (Francia), PCCW Global (Hong Kong), Tata Communications (India) y Verizon (Estados Unidos). Los operadores TIER 1 en general despliegan cables submarinos para interconectar continente, además de cables terrestres para cubrir el área intra-continental.
8.1.2. Tier 2
Son operadores de ámbito regional que no pueden alcanzar todos los puntos de Internet, por lo tanto, necesitan conectarse a una red TIER 1. Su principal función es ofrecer servicios de conectividad a los operadores TIER 3. Algunos ejemplos de operadores TIER 2 en LATAM son: Columbus Networks, GlobeNet, Internexa, Ufinet, Silica Networks e IFX Corporation. Los operadores TIER 2 en general despliegan cables terrestres para lograr conectividad entre ciudades además de cables submarinos en caso de buscar cubrir grandes distancias.
8.1.3. Tier 3
Pertenecen a los operadores que dan servicio de conexión a Internet a los usuarios finales, tales como: residenciales, empresas, universidades, entidades gubernamentales, etc. A estos se les denomina típicamente como ISP (Internet Service Provider) o proveedores de acceso a Internet. Algunos ejemplos en Latinoamérica son: Telecom Argentina, Comteco, Nuevatel, Telefónica Celular de Bolivia, Telefónica Brasil, Claro Brasil, Telefónica Chile, Claro Chile, Entel Chile, Claro Colombia, EPM Telecomunicaciones, Tigo Colombia, CNT, Conecel, Otecel, Claro Perú, Media Networks (Telefónica), Entel Perú, CO.PA.CO, Giganet, Tigo Paraguay, ANTEL, Movistar Uruguay, Telstar. En general las redes TIER 3 despliegan principalmente tendidos de fibra óptica o redes inalámbricas de larga distancia para lograr conectividad entre ciudades de un mismo país. Además, cuentan con redes de acceso orientadas tanto a cobertura masiva como a nichos específicos a través de tecnología satelital, FTTH, WiFi, Ethernet, 4G, 5G, entre otras, dependiendo del tipo de servicio que busque ofrecer.
8.2. Dirección IP
8.2.1. IPv4
IPv4 (Internet Protocol versión 4) es el formato de dirección estándar que permite que todas las máquinas en Internet se comuniquen entre sí. IPv4 se escribe como una cadena de dígitos de 32 bits y una dirección IPv4 se compone de cuatro números entre 0 y 255, separados por puntos.
8.2.2. IPv6
IPv6 (Internet Protocol versión 6) es un estándar actualizado para identificar ordenadores en Internet. Al igual que IPv4, proporciona un identificador único a cada dispositivo, pero uno que se ha ajustado para adaptarse al creciente número de ordenadores conectados a Internet en la actualidad.
IPv6 aumenta el número de direcciones IP posibles desde los 4 mil millones de IPv4 hasta los 340 billones de billones de billones. IPv6 se escribe como una cadena hexadecimal de dígitos de 128 bits, y una dirección IPv6 típica es algo así:
2001:0ab8:85a2:0000:0000:8a3e:0370:7334
IPv6 se ha optimizado para estar al día con el Internet modernizado de la actualidad. Esto significa deshacerse de ciertos componentes del sistema IPv4 que ya no son necesarios.
8.3. Intranet
Las empresas usan las Intranets para que los empleados de los diferentes departamentos accedan la información necesaria para el desarrollo de su actividad.
La información compartida puede variar según la empresa, son muy habituales las redes para compartir documentos y bases de datos de gestión. Muchas aplicaciones corporativas pueden considerarse dentro de esta definición.
8.3.1. VPN
VPN son las siglas de Virtual Private Network. Una conexión VPN lo que te permite es crear una red local sin necesidad que sus integrantes estén físicamente conectados entre sí, sino a través de Internet. Obtienes las ventajas de la red local (y alguna extra), con una mayor flexibilidad, pues la conexión es a través de Internet y puede por ejemplo ser de una punta del mundo a la otra.
8.3.2. LAN
Una red de área local (LAN) es un grupo de computadoras y dispositivos periféricos que comparten una línea de comunicaciones común o un enlace inalámbrico a un servidor dentro de un área geográfica específica. Una red de área local puede servir a tan solo dos o tres usuarios en una oficina en casa o miles de usuarios en la oficina central de una corporación.
8.3.3. WAN
Una red de área amplia (WAN) es la tecnología que conecta entre sí a las oficinas, los centros de datos, las aplicaciones en la nube y el almacenamiento en la nube. Se denomina red de área amplia porque se extiende más allá de un solo edificio o un gran recinto para incluir múltiples ubicaciones repartidas a lo largo de una zona geográfica concreta, o incluso del mundo. Por ejemplo, las empresas con muchas sucursales internacionales utilizan una WAN para conectar las redes de las oficinas entre sí. La WAN más grande del mundo es Internet puesto que se trata de un conjunto de muchas redes internacionales que se conectan entre sí.
8.3.4. DMZ
Una zona desmilitarizada (demilitarized zone, DMZ) es una red perimetral que protege la red de área local (local-area network, LAN) interna contra el tráfico no confiable.
Un significado común para una DMZ es una subred que se encuentra entre la Internet pública y las redes privadas. Expone los servicios externos a redes no confiables y agrega una capa adicional de seguridad para proteger los datos confidenciales almacenados en redes internas, utilizando firewalls para filtrar el tráfico.
El objetivo final de una DMZ es permitir que una organización acceda a redes no confiables, como Internet, a la vez que garantiza que su red privada o LAN permanecen seguras.
8.4. Paquetes
8.4.1. TCP (Transmission Control Protocol)
El Protocolo TCP/IP o Transfer Control Protocol consiste en un acuerdo estandarizado sobre el que se realiza la transmisión de datos entre los participantes de una red informática.
La importancia de TCP es que asegura que los mensajes son recibidos en el mismo orden en que son enviados. Por lo que es ideal para el envío de documentos como HTML y aplicaciones de Chat.
8.4.2. UDP (User Datagram Protocol)
Debido a que el protocolo TCP, aunque proporciona seguridad, también retrasa la transmisión, David Patrick Reed publicó en 1980 su idea del protocolo de datagramas de usuario (User datagram protocol o UDP) como una alternativa más simple y rápida al protocolo estándar.
El protocolo UDP es una alternativa directa al protocolo más utilizado, el TCP, aunque ambos se diferencian sobre todo en un punto: mientras que la transmisión en el protocolo TCP tiene lugar una vez se ha producido el enlace obligatorio de 3 vías (con acuse de recibo mutuo entre el emisor y el receptor, incluida la sesión de comunicación), el protocolo UDP no utiliza este procedimiento con el fin de mantener el tiempo de transmisión lo más bajo posible.
Un ejemplo común es la transmición de video en vivo (VideoLlamadas, Streaming).
8.4.3. ICMP (Internet Control Message Protocol)
El Protocolo de control de mensajes de Internet (ICMP) se utiliza para diagnosticar problemas de red en Internet. El ICMP se utiliza principalmente para determinar si los datos llegan o no a su destino a su debido tiempo. El ICMP es crucial para informar de errores y realizar pruebas, pero también se puede utilizar en ataques de denegación de servicio distribuido (DDoS) (Ping de la Muerte).
8.5. Herramientas
8.5.1. whois
Nos permite revisar si un dominio ya se encuentra registrado.
$ whois ninjas.cl
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object
refer: whois.nic.cl
domain: CL
[...]
8.5.2. ping
Nos permite ver si un servidor está respondiendo.
$ ping ninjas.cl
PING ninjas.cl (190.107.177.35): 56 data bytes
64 bytes from 190.107.177.35: icmp_seq=0 ttl=58 time=23.956 ms
64 bytes from 190.107.177.35: icmp_seq=1 ttl=58 time=18.623 ms
64 bytes from 190.107.177.35: icmp_seq=2 ttl=58 time=18.846 ms
64 bytes from 190.107.177.35: icmp_seq=3 ttl=58 time=18.614 ms
^C
--- ninjas.cl ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 18.614/20.010/23.956/2.280 ms
8.5.3. traceroute
Nos permite tener trazabilidad sobre donde viajan los paquetes.
$ traceroute ninjas.cl
traceroute to ninjas.cl (190.107.177.35), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 4.532 ms 2.967 ms 3.716 ms
2 * * *
3 192.168.182.186 (192.168.182.186) 14.507 ms 13.943 ms 12.952 ms
4 * * *
5 192.168.99.29 (192.168.99.29) 19.805 ms 16.914 ms 19.183 ms
6 wirenet-265831.scl.pitchile.cl (45.68.16.159) 19.812 ms 17.184 ms 18.760 ms
7 * * *
8 * * *
8.5.4. netstat
Nos permite ver las conexiones abiertas.
$ netstat
Active Internet connections
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 0 0 192.168.0.9.50417 ec2-35-163-144-2.https ESTABLISHED
tcp4 0 0 localhost.63342 localhost.50416 ESTABLISHED
tcp4 0 0 localhost.50416 localhost.63342 ESTABLISHED
tcp6 0 0 2800:150:14a:174.50411 whatsapp-cdn6-sh.https ESTABLISHED
tcp6 0 0 2800:150:14a:174.50320 2800:3f0:4003:c0.https ESTABLISHED
tcp6 0 0 2800:150:14a:174.50319 2800:3f0:4003:c0.https ESTABLISHED
tcp6 0 0 2800:150:14a:174.50299 2800:3f0:4003:c0.https ESTABLISHED
tcp6 0 0 2800:150:14a:174.50296 2800:3f0:4003:c0.https ESTABLISHED
tcp4 0 0 192.168.0.9.50294 149.154.175.54.https ESTABLISHED
tcp4 0 0 192.168.0.9.50139 192.168.0.8.52148 ESTABLISHED
tcp4 0 0 192.168.0.9.50159 55.65.117.34.bc..https ESTABLISHED
tcp4 0 0 192.168.0.9.50157 ec2-54-71-185-24.https ESTABLISHED
tcp6 0 0 2800:150:14a:174.50155 2800:3f0:4003:c0.https ESTABLISHED
tcp4 0 0 192.168.0.9.50153 ec2-54-173-95-25.https ESTABLISHED
tcp4 0 0 192.168.0.9.50151 ec2-3-232-128-21.https ESTABLISHED
tcp6 0 0 2800:150:14a:174.50145 whatsapp-cdn6-sh.https ESTABLISHED
tcp4 0 0 192.168.0.9.50141 149.154.175.50.https ESTABLISHED
tcp4 0 0 localhost.63342 localhost.49772 ESTABLISHED
tcp4 0 0 localhost.49772 localhost.63342 ESTABLISHED
tcp4 0 0 192.168.0.9.50968 249.195.120.34.b.443 ESTABLISHED
tcp4 0 0 192.168.0.9.50933 17.57.144.40.5223 ESTABLISHED
udp4 0 0 *.59915 *.*
udp4 0 0 *.xserveraid *.*
udp4 0 0 *.* *.*
[....]
8.5.5. nslookup
Permite ver los datos de un dominio.
$ nslookup
> www.ninjas.cl
Server: 2800:150:e:4::4
Address: 2800:150:e:4::4#53
Non-authoritative answer:
www.ninjas.cl canonical name = ninjas.cl.
Name: ninjas.cl
Address: 190.107.177.35
8.5.6. ifconfig / ip
Nos permite ver nuestra dirección IP local.
$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=400<CHANNEL_IO>
ether d4:61:9d:1d:89:90
inet6 fe80::469:56de:4f74:fe68%en0 prefixlen 64 secured scopeid 0x4
inet 192.168.0.9 netmask 0xffffff00 broadcast 192.168.0.255
inet6 2800:150:14a:174f:18f5:d82e:f403:2091 prefixlen 64 autoconf secured
inet6 2800:150:14a:174f:8994:3b2d:4707:3179 prefixlen 64 autoconf temporary
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
[...]
8.5.7. Wireshark
Wireshark nos permite analizar los paquetes enviados y recibidos. Útil para realizar ingeniería inversa sobre servidores propietarios, analizando la comunicación cliente-servidor.
8.5.8. Myip
Permiten verificar la dirección IP que tenemos asignada. Útil para revisar si la conexión a VPN es exitosa.
8.5.9. Otros Servicios
-
https://downforeveryoneorjustme.com/: Permite verificar si el servicio está disponible.
-
https://builtwith.com/: Permite saber qué tecnologías utilizan los sistemas web.
8.6. Ejercicio 1: Demostración de envío de Paquetes TCP
Utilizando el comando nc (netcat)
podemos crear un cliente y servidor
que nos permita demostrar el envío de un paquete utiizando TCP.
Paso 1: Creamos nuestro servidor
$ nc -l 3000
Paso 2: Creamos nuestro cliente en la ip local (en otra terminal)
$ nc 127.0.0.1 3000
Paso 3: Si utilizamos el comando netstat
podremos ver las conexiones abiertas.
$ netstat -an | grep 3000
$ netstat -an | grep 3000
tcp4 0 0 127.0.0.1.3000 127.0.0.1.49557 ESTABLISHED
tcp4 0 0 127.0.0.1.49557 127.0.0.1.3000 ESTABLISHED
tcp4 0 0 *.3000 *.* LISTEN
Paso 4: En la terminal del cliente escribimos un mensaje para ser enviado.
$ nc 127.0.0.1 3000
hola
Paso 5: Verificamos que el servidor lo recibió.
$ nc -l 3000
hola
Paso 6: Al abrir Wireshark podremos analizar los paquetes TCP enviados.
8.7. Registros DNS (Zona)
Cuando registra un dominio, se crea un archivo de zona (conjunto de registros DNS) para ese dominio. La configuración contenida en el archivo de zona solo funciona si los servidores de nombres de su dominio apuntan al hosting, si los servidores de nombres apuntan a otra empresa, entonces el dominio estaría utilizando la configuración de DNS de la otra empresa.
8.7.1. CNAME
CNAME (Canonical Name) es un nombre de host que apunta a otro nombre de host (info.mi-dominio.net a info.mi-dominio.com). Los propietarios de dominios generalmente lo usan para apuntar un dominio o subdominio a otro nombre de dominio (los subdominios normales solo pueden apuntar a un directorio dentro de su cuenta de alojamiento).
Utilizado normalmente para Github Pages.
8.7.2. A Record
Asigna una dirección para tu dominio a una IP específica (www a 12.345.678.90). Los símbolos @ y www se utilizan para indicar el propio dominio raíz. Por ejemplo, un registro @ A para dominio.com es lo mismo que dominio.com apuntando a una determinada IP, y cuando agrega www a un registro A es lo mismo que www.dominio.com para apuntar a una determinada IP. Normalmente usado Para controlar qué servidores específicos alojan una función particular asociada con su presencia en línea (sitio web, correo electrónico, etc.). Muchos otros registros DNS requieren un registro A asociado para funcionar correctamente.
8.7.3. AAAA Record
El registro AAAA especifica la dirección IP (IPv6) para un host dado. Por lo general, resuelve un nombre de dominio (o apunta el nombre de dominio) a la ubicación correcta por medio de la dirección IPv6.
8.7.4. MX Record
Un nombre de host que define los servidores de recepción de correo y la prioridad en la que se usa cada servidor en caso de que un servidor no pueda recibir correo. Para utilizar un servicio de correo electrónico diferente al de su proveedor de alojamiento o para designar servidores personales como respaldos de correo en caso de que las opciones de correo predeterminadas fallen. Utilizado normalmente para servidores de correo externos. Ejemplo Google Workspace.
8.7.5. TXT/SPF Record
Un Sender Policy Framework (marco de políticas de remitente), ayuda a reducir el spam y la suplantación de dominio. Para verificar la seguridad del dominio, utilícelo con servicios externos, como Google Analytics.
8.7.6. Name Server Record
Un nombre de host que apunta a un servidor de nombres específico (shop.tu-dominio.com a ns1.example.com). Para administrar todos los demás registros. Los cambios en los registros A, registros MX y otros registros DNS deben realizarse donde se encuentran sus servidores de nombres.
8.7.7. Private Name Server
Le permite definir sus propios servidores de nombres en lugar de utilizar los genéricos proporcionados por nosotros (ns1.tu-dominio.com en lugar de ns1.empresa-hosting.com). Para mantener el anonimato entre su negocio en línea y su proveedor de alojamiento, o para utilizar alojamiento en su VPS o servidor dedicado.
8.7.8. SRV Record
Los registros SRV (servicio) son registros DNS personalizados que se utilizan para establecer conexiones entre un servicio y un nombre de host. Cuando una aplicación necesita encontrar una ubicación de servicio específica, buscará un registro SRV relacionado. No todas las empresas de hosting soportan esta configuración.
8.7.9. TTL (Time To Live)
El valor de tiempo de vida (TTL) determina cuánto tiempo un servidor DNS, como el ISP, almacena en caché el registro. Lo recomendable es dejar el TTL en su configuración predeterminada. Los cambios en los registros DNS, como los registros A, MX y CNAME, suelen tardar de 4 a 8 horas en aplicarse por completo.
Enlaces
8.8. Protocolos
8.8.1. HTTP
HTTP, de sus siglas en inglés: "Hypertext Transfer Protocol", es el nombre de un protocolo el cual nos permite realizar una petición de datos y recursos, como pueden ser documentos HTML. Es la base de cualquier intercambio de datos en la Web, y un protocolo de estructura cliente-servidor, esto quiere decir que una petición de datos es iniciada por el elemento que recibirá los datos (el cliente), normalmente un navegador Web. Así, una página web completa resulta de la unión de distintos sub-documentos recibidos, como, por ejemplo: un documento que especifique el estilo de maquetación de la página web (CSS), el texto, las imágenes, vídeos, scripts, etc.
HTTP 1.0
Se finalizó y se documentó completamente en 1996. Cada solicitud al mismo servidor requiere una conexión TCP separada.
HTTP 1.1
Se publicó en 1997. Una conexión TCP se puede dejar abierta para su reutilización (conexión persistente), pero no resuelve el problema de bloqueo HOL (head-of-line). El Bloqueo HOL es cuando se agota la cantidad de solicitudes paralelas permitidas en el navegador, las solicitudes posteriores deben esperar a que se completen las anteriores.
HTTP 2.0
Se publicó en 2015. Aborda el problema de HOL a través de la multiplexación de solicitudes, lo que elimina el bloqueo de HOL en la capa de aplicación, pero HOL todavía existe en la capa de transporte (TCP). HTTP 2.0 introdujo el concepto de "flujos" HTTP: una abstracción que permite multiplexar diferentes intercambios HTTP en la misma conexión TCP.
HTTP 3.0
El primer borrador de HTTP 3.0 se publicó en 2020. Es el sucesor propuesto de HTTP 2.0. Utiliza QUIC en lugar de TCP para el protocolo de transporte subyacente, eliminando así el bloqueo HOL en la capa de transporte.
QUIC se basa en UDP. Presenta flujos como ciudadanos de primera clase en la capa de transporte. Los flujos QUIC comparten la misma conexión QUIC, por lo que no se requieren protocolos de enlace adicionales ni inicios lentos para crear otros nuevos, pero los flujos QUIC se entregan de forma independiente, de modo que en la mayoría de los casos, la pérdida de paquetes que afecta a un flujo no afecta a los demás.
8.8.2. FTP (File Transfer Protocol)
Protocolo utilizado para transferencia de archivos.
Programas
8.9. Modelo TCP/IP
El modelo de interconexión de sistemas abiertos (OSI) describe siete capas que los sistemas informáticos utilizan para comunicarse a través de una red. Fue el primer modelo estándar para comunicaciones en red, adoptado por todas las principales empresas de informática y telecomunicaciones a principios de la década de 1980.
La Internet moderna no se basa en OSI, sino en el modelo TCP/IP más simple. Sin embargo, el modelo OSI de 7 capas todavía se usa ampliamente, ya que ayuda a visualizar y comunicar cómo funcionan las redes, y ayuda a aislar y solucionar problemas de red.
OSI fue presentado en 1983 por representantes de las principales empresas de informática y telecomunicaciones, y fue adoptado por ISO como estándar internacional en 1984.
El protocolo más popular en uso en la actualidad es el Protocolo de control de transmisión/Protocolo de Internet (TCP/IP). Actualmente, Internet y la mayoría de las intranets empresariales utilizan TCP/IP debido a su popularidad, flexibilidad, compatibilidad y capacidad de implementación en redes grandes y pequeñas.
El modelo TCP/IP consta de cuatro capas en lugar de las siete del modelo OSI. Las cuatro capas del modelo TCP/IP se correlacionan con las siete capas del modelo OSI, pero las capas del modelo TCP/IP combinan varias capas del modelo OSI.
Cuando se analizan los diferentes protocolos en la pila de IP, las capas de los modelos OSI y TCP/IP son intercambiables. En otras palabras, la capa de Internet y la capa de red describen lo mismo, al igual que las capas de transporte, las otras dos capas del modelo TCP/IP están compuestas por múltiples capas del modelo OSI.
TCP/IP es de código abierto; sus estándares y protocolos se definen en un foro público a través del IETF (Grupo de trabajo de ingeniería de Internet (IETF)) y se publican mediante RFC (Solicitudes de comentarios).
El envío de un mensaje a través de las capas varía según su dirección, es decir, el mensaje de origen tiene que empezar desde la capa superior a la inferior, y cuando llega a su destino, empieza desde la capa inferior a la superior.
8.9.1. Capa 4. Capa de aplicación
La capa de aplicación es la capa superior del modelo TCP/IP; la capa de aplicación define los protocolos de aplicación TCP/IP y cómo los programas host interactúan con los servicios de la capa de transporte para usar la red.
La capa de aplicación incluye todos los protocolos de nivel superior, como DNS, HTTP, Telnet, SSH, FTP, TFTP, SMTP, DHCP, X Window, RDP, etc.
8.9.2. Capa 3. Capa de transporte
La capa de transporte es la tercera capa del modelo TCP/IP, el propósito de la capa de transporte es permitir que los dispositivos host de origen y destino mantengan una conversación. La capa de transporte define el nivel de servicio y el estado de la conexión utilizada para transportar los datos.
Los principales protocolos incluidos en la capa de transporte son TCP (Transmission Control Protocol) y UDP (User Datagram Protocol).
8.9.3. Capa 2. Capa de Internet
La capa de Internet es la segunda capa del modelo TCP/IP de cuatro capas. La capa de Internet proporciona la información de la dirección de origen y destino (dirección lógica o dirección IP) para reenviar datos entre hosts a través de la red; la capa de Internet también es responsable de enrutar datagramas IP.
Los principales protocolos incluidos en la capa de Internet son IP (Protocolo de Internet), ICMP (Protocolo de mensajes de control de Internet), ARP (Protocolo de resolución de direcciones), RARP (Protocolo de resolución de direcciones inversa) e IGMP (Protocolo de gestión de grupos de Internet).
8.9.4. Capa 1. Capa de acceso a la red
La capa de acceso a la red, también conocida como capa de acceso al medio, es la primera capa del modelo TCP/IP. La capa de acceso a la red define cómo se envían físicamente los datos a través de la red, incluido cómo los dispositivos físicos (hardware) señalan y envían los bits que interactúan directamente con un medio de red, por ejemplo, un cable coaxial, fibra óptica, cable de cobre de par trenzado, de forma inalámbrica, etc
Los protocolos incluidos en la capa de acceso a la red son Ethernet, Token Ring, FDDI, X.25, Frame Relay, entre otros, siendo el más popular Ethernet.
8.9.5. Ejemplo: Página Web
Ejemplificamos la comunicación por TCP/IP mediante un caso de una página web hospedada en un servidor web, la cual es transmitida hacia un cliente (navegador).
Capa | PDU (Protocol Data Unit) Mensajes Encapsulados |
---|---|
Aplicación |
Datos |
Transporte |
Segmentos |
Red |
Paquetes |
Enlace de Datos |
Tramas |
Física |
Bits |
Servidor
El servidor transforma la información a un formato transportable por el medio físico y se envía al cliente.
Capa | Descripción | |
---|---|---|
Aplicación |
Toma el contenido de la página web creado por un framework o un archivo html. Opcionalmente las encripta (SSL/TLS). Transforma los datos a binario. Se agregan los encabezados del protocolo HTTP (Ej. 200 OK) |
|
Transporte |
Si la página tiene un tamaño mayor a 1500 bytes, el contenido es fragmentado en paquetes más pequeños. Enviado utilizando los protocolos TCP que agregan (encapsulan) sus propios encabezados (por ejemplo puertos de origen y destino). |
|
Red |
Los contenidos ya no serán alterados. Entra en acción el protocolo IP y encapsula agregando sus encabezados (Ej. IP de origen e IP destino), esto se conoce como información de direccionamiento lógico. |
|
Enlace de Datos |
Encapsula y agrega un encabezado header (dirección MAC origen {servidor} y dirección MAC destino {cliente}) y un encabezado trailer (Detección de Errores) |
|
Física |
Luego de ser encapsulada por todas las capas anteriores. No se agregan más encabezados y es transformada a un medio físico como señales eléctricas, ondas electromagnéticas o señales de luz y es enviada hacia el cliente web. |
Cliente
El cliente aplica el proceso inverso y finalmente muestra el resultado en el navegador web.
Capa | Descripción |
---|---|
Física |
Decodifica el mensaje transformando las señales eléctricas, electromagnéticas o de luz a código binario. |
Enlace de Datos |
Desencapsula, quitando los encabezados de header y trailer respectivos. |
Red |
Desencapsula, quitando los encabezados de IP respectivos. |
Transporte |
Desencapsula, quitando los encabezados de TCP respectivos. Agrupa todos los segmentos (o fragmentos) para formar un solo archivo |
Aplicación |
Desencapsula, quitando los encabezados de HTTP. Transformando la información binaria a caracteres legibles por el ser humano y finalmente construir el sitio web en el navegador. |
9. HTTP, JSON y APIS
HTTP es el protocolo en el que se basa la Web. Fue inventado por Tim Berners-Lee entre los años 1989-1991, HTTP ha visto muchos cambios, manteniendo la mayor parte de su simplicidad y desarrollando su flexibilidad. HTTP ha evolucionado, desde un protocolo destinado al intercambio de archivos en un entorno de un laboratorio semi-seguro, al actual laberinto de Internet, sirviendo ahora para el intercambio de imágenes, vídeos en alta resolución y en 3D.
9.1. Cabeceras (Headers)
El concepto de cabeceras de HTTP, se presentó tanto para las peticiones (requests) como para las respuestas (responses), permitiendo la trasmisión de meta-data y conformando un protocolo muy versátil y ampliable. Con el uso de las cabeceras de HTTP, se pudieron transmitir otros documentos además de HTML, mediante la cabecera Content-Type.
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
Una pagina web con una imagen
<IMG SRC="/miImagen.gif">
</HTML>
9.2. Métodos
HTTP define una serie predefinida de métodos de petición (algunas veces referido como "verbos") que pueden utilizarse. El protocolo tiene flexibilidad para ir añadiendo nuevos métodos y para así añadir nuevas funcionalidades. Cada método indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa depende de la aplicación del servidor. Por ejemplo, el recurso puede corresponderse con un archivo que reside en el servidor.
9.3. Códigos de Respuesta
El código de respuesta, estado o retorno es un número que indica que ha pasado con la petición. El resto del contenido de la respuesta dependerá del valor de este código. El sistema es flexible y de hecho la lista de códigos ha ido aumentando para así adaptarse a los cambios e identificar nuevas situaciones. Cada código tiene un significado concreto. Sin embargo el número de los códigos están elegidos de tal forma que según si pertenece a una centena u otra se pueda identificar el tipo de respuesta que ha dado el servidor:
-
Códigos con formato 1xx: Respuestas informativas. Indica que la petición ha sido recibida y se está procesando.
-
Códigos con formato 2xx: Respuestas correctas. Indica que la petición ha sido procesada correctamente.
-
Códigos con formato 3xx: Respuestas de redirección. Indica que el cliente necesita realizar más acciones para finalizar la petición.
-
Códigos con formato 4xx: Errores causados por el cliente. Indica que ha habido un error en el procesado de la petición a causa de que el cliente ha hecho algo mal.
-
Códigos con formato 5xx: Errores causados por el servidor. Indica que ha habido un error en el procesado de la petición a causa de un fallo en el servidor.
Enlaces
9.4. REST
En el año 2000, un nuevo formato para usar HTTP fue diseñado: REST (del inglés: 'Representational State Transfer'). Las acciones de la nueva API, no estaban supeditadas a nuevos métodos HTTP, unicamente al acceso a URIs especificas con métodos HTTP/1.1). Esto permitió que cualquier aplicación Web dispusiera de una API, para permitir la recuperación y modificación de datos, sin tener que actualizar servidores o navegadores; todo lo que se necesitaba era incluido en los archivos servidos por los sitios Web. La contrapartida del modelo REST está en que cada sitio Web define su propia versión no estándar de API RESTful y tiene un control total sobre ella; al contrario del formato *DAV donde clientes y servidores eran interoperables. La arquitectura REST empezó a ser muy común a partir del año 2010.
9.4.1. Cabeceras Más Usadas
| Cabecera | Descripción | Ejemplo | |---------------------------------------------------------|------------|------------| | Content-Type | Define el tipo de contenido que se envía en la petición | application/json | | Accept | Define el tipo de contenido que se aceptará en la respuesta | application/json | |https://developer.mozilla.org/es/docs/Web/HTTP/Headers/Authorization[Authorization]|Permite enviar tokens de autorización.| Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l|
9.4.2. Métodos Más Usados
Método | Uso recomendado | Códigos de Estado Comunes |
---|---|---|
Obtener información |
200, 404, 403 |
|
Permite crear recursos |
201, 202, 404, 403 |
|
Permite actualizar recursos en su totalidad |
200, 404, 403 |
|
Permite actualizar un campo dentro de un recurso |
200, 404, 403 |
|
Permite eliminar un recurso |
200, 404, 403 |
Nota: No se recomienda el código de estado 204 (No content) debido a que no entrega ninguna respuesta (body) al cliente. Es mejor siempre devolver un cuerpo con información relacionada a la operación.
9.4.3. JSON API
JSON API es una convención (no un estándar) para expresar datos de APIs en formato JSON o json api. Es decir, es un JavaScript Object Notation en una Interfaz de Programación en Aplicaciones. También puedes pensar en JSON API como un formato que trabaja con HTTP.
9.4.4. Open API
La especificación OpenAPI es un lenguaje de especificación para API HTTP que proporciona un medio estandarizado para definir su API ante otros. Puede descubrir rápidamente cómo funciona una API, configurar la infraestructura, generar código de cliente y crear casos de prueba para sus API. Obtenga más información sobre cómo puede obtener el control de sus API ahora, comprender el ciclo de vida completo de las API y comunicarse con las comunidades de desarrolladores dentro y fuera de su organización.
9.5. Otros Tipos de APIS
9.5.1. SOAP
SOAP es una tecnología antigua que requiere un contrato de comunicación estricto entre sistemas. Con el tiempo, se han agregado nuevos estándares de servicios web para adaptarse a los cambios tecnológicos, pero generan gastos generales adicionales. REST se desarrolló después de SOAP y soluciona de forma inherente muchas de sus deficiencias. Los servicios web REST también se denominan servicios web RESTful.
9.5.2. GraphQL
GraphQL es un lenguaje de consulta para API y un tiempo de ejecución para completar esas consultas con sus datos existentes. GraphQL proporciona una descripción completa y comprensible de los datos de su API, brinda a los clientes el poder de solicitar exactamente lo que necesitan y nada más, facilita la evolución de las API con el tiempo y habilita potentes herramientas para desarrolladores.
{
hero {
name
friends {
name
homeWorld {
name
climate
}
species {
name
lifespan
origin {
name
}
}
}
}
}
9.5.3. gRPC
gRPC es un marco moderno de llamada a procedimiento remoto (RPC) de código abierto y alto rendimiento que puede ejecutarse en cualquier entorno. Puede conectar de manera eficiente servicios dentro y entre centros de datos con soporte conectable para equilibrio de carga, rastreo, verificación de estado y autenticación. También es aplicable en la última milla de la informática distribuida para conectar dispositivos, aplicaciones móviles y navegadores a servicios backend.
9.6. Formatos de Archivos
Existen diversos formatos y estándares para compartir datos y configurar los productos de software. Normalmente son formatos de texto plano (pueden ser leidos por un humano) y también hay en formato binario (pueden ser leidos solo por un computador), entre los más populares están JSON, XML, YAML y TOML.
9.6.1. Formatos de Serialización
Siempre que desee enviar alguna estructura de datos o un objeto a través de redes informáticas, digamos Internet, debe convertirlo en un formato especial para leerlo y almacenarlo. El proceso se conoce comúnmente como serialización y es de enorme importancia en la web. Un ejemplo de uso común de serialización es al leer datos de bases de datos y transferirlos a través de la web.
Algunas formaciones de serialización incluyen JSON y XML.
JSON
JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - Diciembre 1999. JSON es un formato de texto que es completamente independiente del lenguaje pero utiliza convenciones que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos.
Ejemplo
{
"squadName": "Super hero squad",
"homeTown": "Metro City",
"formed": 2016,
"secretBase": "Super tower",
"active": true,
"members": [
{
"name": "Molecule Man",
"age": 29,
"secretIdentity": "Dan Jukes",
"powers": ["Radiation resistance", "Turning tiny", "Radiation blast"]
},
{
"name": "Madame Uppercut",
"age": 39,
"secretIdentity": "Jane Wilson",
"powers": [
"Million tonne punch",
"Damage resistance",
"Superhuman reflexes"
]
},
{
"name": "Eternal Flame",
"age": 1000000,
"secretIdentity": "Unknown",
"powers": [
"Immortality",
"Heat Immunity",
"Inferno",
"Teleportation",
"Interdimensional travel"
]
}
]
}
XML
El lenguaje de marcado extensible (XML) permite definir y almacenar datos de forma compartible. XML admite el intercambio de información entre sistemas de computación, como sitios web, bases de datos y aplicaciones de terceros. Las reglas predefinidas facilitan la transmisión de datos como archivos XML a través de cualquier red, ya que el destinatario puede usar esas reglas para leer los datos de forma precisa y eficiente.
Ejemplo
<libro>
<título>Introducción a Amazon Web Services</título>
<autor>Mark Wilkins</autor>
</libro>
9.6.2. Formatos de Configuración
Los formatos de configuración son más adecuados para establecer parámetros en los programas, más que enviar información por las vías de comunicación. Algunos formatos son YAML y TOML. JSON también es comunmente usado como un formato de configuración, aunque algunos prefieren utilizar variantes como JSONC que incluye comentarios.
YAML
YAML es un lenguaje sencillo que las personas pueden comprender y suele utilizarse en el diseño de archivos de configuración. Para algunas personas, YAML significa otro lenguaje de marcado más; para otras, es un acrónimo recursivo que quiere decir "YAML no es un lenguaje de marcado", lo que enfatiza la idea de que se utiliza para los datos, no para los documentos.
Ejemplo
name:John
age:18
Hobbies:
Hobby1:Football
Hobby2:BasketBall
Hobby3:Hockey
Job:
-System administrator
-Programmer
TOML
TOML se abrevia como Tom’s Obvious Markup Language. TOML pretende ser un formato de archivo de configuración mínimo que sea fácil de leer debido a una semántica obvia. TOML está diseñado para asignarse sin ambigüedades a una tabla hash. TOML debería ser fácil de analizar en estructuras de datos en una amplia variedad de lenguajes.
Ejemplo
# This is a TOML document
title = "TOML Example"
[owner]
name = "Tom Preston-Werner"
dob = 1979-05-27T07:32:00-08:00
[database]
enabled = true
ports = [ 8000, 8001, 8002 ]
data = [ ["delta", "phi"], [3.14] ]
temp_targets = { cpu = 79.5, case = 72.0 }
[servers]
[servers.alpha]
ip = "10.0.0.1"
role = "frontend"
[servers.beta]
ip = "10.0.0.2"
role = "backend"
9.7. Clientes APIs
9.7.1. Postman
Postman es una plataforma API para crear y utilizar API. Postman simplifica cada paso del ciclo de vida de la API y agiliza la colaboración para que puedas crear mejores API, más rápido.
9.7.2. Insomnia
Kong Insomnia es una plataforma colaborativa de desarrollo de API de código abierto que facilita la creación de API de alta calidad, sin la sobrecarga y el desorden de otras herramientas.
9.7.3. Hoppscotch
Hoppscotch es una suite de desarrollo de API liviana basada en web. Fue creada desde cero teniendo en cuenta la facilidad de uso y la accesibilidad, brindando toda la funcionalidad necesaria para los desarrolladores de API con una interfaz de usuario minimalista y discreta.
10. Seguridad de Aplicaciones Web
11. HTML, CSS y GIT
HTML (Lenguaje de Marcas de Hipertexto, del inglés HyperText Markup Language) es el componente más básico de la Web. Define el significado y la estructura del contenido web. Además de HTML, generalmente se utilizan otras tecnologías para describir la apariencia/presentación de una página web (CSS) o la funcionalidad/comportamiento (JavaScript).
11.1. Algunos Templates de Ejemplo
11.2. Buenas Prácticas
11.2.1. Comenzar por el DOCTYPE
<!DOCTYPE>
informa al navegador qué versión de HTML (o XML) se usó para escribir el documento. Doctype es una declaración no una etiqueta. Además, podemos referirnos a ella como "document type declaration" o por las siglas "DTD".
Para los documentos html el tag recomendado es:
<!DOCTYPE html>
11.2.2. Usar minúsculas en los tags
El utilizar mayúsculas era muy popular en los primeros años, pero hoy en día se recomienda utilizar los tags en minúsculas.
<UL></UL> <!-- Es válido, pero no recomendable -->
<ul></ul> <!-- Es mejor usar los tags en minúsculas -->
11.2.3. Utilizar UTF-8
La etiqueta <meta charset="">
permite definir que caracteres son los utilizados
por el documento. En los primeros días, había muchas opciones como Windows-1252
.
Sin embargo hoy en día utilizar utf-8
es lo recomendado y cualquier
lenguaje humano puede ser mostrado con dicha codificación.
<meta charset="utf-8">
11.2.4. Utilizar CSS
En los primeros días, antes de CSS se incluían los estilos dentro de los tags html. Esto llevaba a mucha repetición y suciedad en el código. Siempre utilizar css para dar estilo y formato a los documentos HTML.
<body bgcolor="#000"> <!-- No -->
<body style="background-color: #000"><!-- Válido, pero no recomendado -->
<body class="bg-black"><!-- Se recomienda utilizar clases por sobre estilos inline -->
11.2.5. Mantener un orden coherente
Es recomendable que el orden sea coherente, por ejemplo,
una etiqueta h2
debe venir despúes de una h1
.
<!-- Correcto -->
<h1>Mi Título</h1>
<h2>Mi Subtítuo</h2>
<!-- No recomendable -->
<h1>Mi Título</h1>
<h3>Mi Subtítuo</h3>
11.2.6. Cerrar los tags
Los navegadores hacen todo lo posible para interpretar un documento HTML y mostrar un resultado, aún si las etiquetas son mal usadas o le falta información. El navegador llenará los espacios lo mejor que pueda. Como desarrolladores debemos ser responsables y verificar que las etiquetas se utilicen de forma correcta y esten cerradas apropiadamente.
<head>
<style>
* {
color: white
}
<!-- Se debe cerrar con las etiquetas </style> y </head> antes de partir con body -->
<body></body>
11.2.7. Considerar ayuda a no videntes
Si bien esto no es obligatorio para que un documento sea válido y bien estructurado, considerar a las personas con dificultades de visión u otra condición de diferencia dentro de los elementos para facilitarles la experiencia dentro del sistema web.
11.3. CSS
Hojas de Estilo en Cascada (del inglés Cascading Style Sheets) o CSS es el lenguaje de estilos utilizado para describir la presentación de documentos HTML o XML (en-US) (incluyendo varios lenguajes basados en XML como SVG, MathML o XHTML). CSS describe como debe ser renderizado el elemento estructurado en la pantalla, en papel, en el habla o en otros medios.
Se recomienda aprender a utilizar CSS de forma manual, antes de aventurarse a utilizar frameworks como Bootstrap o Tailwind.
11.3.1. Algunos Frameworks de CSS
Nota: Tailwind es una de las opciones más populares del momento y se recomienda su uso por sobre Bootstrap.
11.3.2. Metodologías
Existen algunas metodologías para organización del CSS. Se recomiendan utilizar si se debe programar mucho CSS personalizado. Aunque en la actualidad se prefiere utilizar herramientas más automatizadas como Tailwind para nombrar las clases.
11.3.3. Transpiladores
Existen algunos transpiladores de CSS como:
Aunque actualmente se prefieren otras alternativas como Tailwind por sobre estos lenguajes intermedios, debido a que las nuevas características de CSS3 implementan mucha de las ideas que estas herramientas brindaban en los primeros años de CSS.
11.3.5. Herramientas de Aprendizaje
11.3.6. Navegador Firefox Developer
Es una versión de Firefox especialmente diseñada para los desarrolladores. Tiene herramientas especiales que permitirán facilitar el trabajar con CSS.
11.4. GIT
¿Qué es un control de versiones, y por qué debería importarte? Un control de versiones es un sistema que registra los cambios realizados en un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante.
Dicho sistema te permite regresar a versiones anteriores de tus archivos, regresar a una versión anterior del proyecto completo, comparar cambios a lo largo del tiempo, ver quién modificó por última vez algo que pueda estar causando problemas, ver quién introdujo un problema y cuándo, y mucho más. Usar un VCS también significa generalmente que si arruinas o pierdes archivos, será posible recuperarlos fácilmente. Adicionalmente, obtendrás todos estos beneficios a un costo muy bajo.
11.4.1. Metodologías
Existen numerosas formas de organizar los proyectos que utilizan Git, tales como Gitflow, Github Flow, Gitlab Flow, pero la más recomendable es el Desarrollo Basado En Tronco.
El desarrollo basado en tronco (o main), consiste en separar las ramas por ambiente, teniendo una rama principal que es la fuente de la verdad donde todos los desarrollos deben basarse.
flowchart TD A1(Rama Main) --> B1 B1(Rama Staging) --> B2(Rama Production)
main (tronco, trunk, master)
La rama principal. Todos los Pull Request deben ser hacia esta rama y no deben tener conflictos con ella. Los desarrolladores crean una rama desde el tronco, para luego mandar su Pull Request, el cual debe estar actualizado con la última versión del tronco main, ser aprobado por los responsables mediante un Code Review y pasar todas las pruebas unitarias.
-
Los desarrolladores realizan pruebas en su ambiente local.
-
Cuando el producto está lo suficientemente maduro y estable, pasa a la siguiente rama que es staging.
-
Se realiza un squash commits al pasar a la siguiente rama.
-
Se crea una nueva etiqueta con la versión de staging.
-
Se elimina la rama transitoria que elaboró el desarrollador (ej: camilo/1085) al hacer un merge exitoso con main.
staging (ambiente de pruebas pre-producción)
Esta es la rama del ambiente de pruebas que replica el ambiente de producción. Este ambiente es el paso anterior a producción y se deben realizar pruebas manuales y automatizadas para validar que el código funcionará y cumplirá las expectativas y requisitos del producto en producción.
-
Una vez se ha validado el producto en este ambiente, pasa a la siguiente rama que es producción.
-
Se realiza un squash commits al pasar a la siguiente rama.
-
Se crea una nueva etiqueta con la versión de producción.
production (ambiente de producción)
Esta es la rama que aloja el producto que es finalmente mostrado al cliente y usuario final. Debe ser el código más
estable, probado y robusto posible, que ha pasado por las pruebas locales y de staging anteriores.
Nunca se debe pasar un código desde main
a production
sin antes pasar por staging
.
11.5. Versionado
Hay diversas formas de versionar el código, entre las más conocidas están: SemVer y Calver. Cada una tiene sus beneficios y complicaciones.
Lo importante es que podemos utilizar las Etiquetas de Git (Tags) para poder marcar cada nueva versión del producto de software dentro de la historia.
La recomendación es usar SemVer si la cantidad de releases es muy frecuente y Calver cuando se realicen releases menos frecuentes.
$ git tag -a v1.4 -m "v1.4"
$ git tag
v0.1
v1.3
v1.4
11.5.1. Changelog
Un changelog (registro de cambios), es un archivo que contiene una lista cronológicamente ordenada de los cambios más destacables para cada versión de un proyecto. Las personas. Ya sean consumidores o desarrolladores, los usuarios finales del software son seres humanos a los que le importa lo que hay en el software. Cuando el software cambia, la gente quiere saber el porqué y el cómo. Si bien utilizar Conventional Commits ayuda, no es recomendable usar el registro de git como changelog y es preferible utilizar un archivo separado y dedicado.
Directrices
-
Están hechos para los seres humanos, no para las máquinas.
-
Debe haber una entrada para cada versión.
-
Los mismos tipos de cambios deben ser agrupados.
-
Versiones y secciones deben ser enlazables.
-
La última versión va primero.
-
Debe mostrar la fecha de publicación de cada versión.
-
Indicar si el proyecto sigue el Versionamiento Semántico.
Tipos de cambios
-
Added
para funcionalidades nuevas. -
Changed
para los cambios en las funcionalidades existentes. -
Deprecated
para indicar que una característica o funcionalidad está obsoleta y que se eliminará en las próximas versiones. -
Removed
para las características en desuso que se eliminaron en esta versión. -
Fixed
para corrección de errores. -
Security
en caso de vulnerabilidades.
Ejemplo
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
## [Unreleased]
## [1.1.1] - 2023-03-05
### Added
- Arabic translation (#444).
Enlaces
11.6. Algunos Comandos
11.6.1. git init
Inicia un nuevo repositorio de git.
$ git init
11.6.2. git add ruta del archivo
Agrega un archivo al registro de git.
$ git add mi_archivo
11.6.3. git status
Muestra el estado actual del historial de cambios por guardar.
$ git status
11.6.4. git commit -m mensaje
El historial de cambios se guarda de forma definitiva, adjuntando un mensaje significativo.
$ git commit -m 'nuevo cambio'
11.6.5. git checkout -b rama
Crea una nueva rama y la asigna como la rama de trabajo actual.
$ git checkout -b mi_rama
$ git checkout -b camilo/1085
Nota: Se recomendaría crear ramas con el formato (nombre usuario)/(número de issue) para ahorrar espacio y facilitar búsquedas al tener mejor orden.
11.6.6. git checkout rama
Cambia hacia una rama que ya existe y la asigna como la rama de trabajo actual.
11.6.7. git merge nombre
Obtiene los cambios de una rama y los combina con los cambios de la rama actual.
$ git merge main
11.6.8. git remote add nombre
repo.remoto.git
Añade un nuevo repositorio remoto.
$ git remote add git@github.com:elixircl/elixir-fullstack.git
-
origin
: Normalmente asignado al repositorio remoto que se tiene permisos de escritura. -
upstream
: Asignado a un repositorio remoto que solamente se tiene lectura.
11.6.9. git clone repo.remoto.git
Clona un repositorio remoto.
$ git clone git@github.com:elixircl/elixir-fullstack.git
11.6.10. git pull nombre del repo remoto
Obtiene los cambios del repositorio remoto y las almacena en nuestra rama local.
$ git pull origin main
11.6.11. git push remoto
rama
Envía nuestros cambios a la rama dentro del repositorio remoto.
$ git push origin main
11.7. Conventional Commits
La especificación de Commits Convencionales es una convención ligera sobre los mensajes de commits. Proporciona un conjunto sencillo de reglas para crear un historial de commits explícito; lo que hace más fácil escribir herramientas automatizadas encima del historial. Esta convención encaja con SemVer, al describir en los mensajes de los commits las funcionalidades, arreglos, y cambios de ruptura hechos.
El mensaje del commit debe ser estructurado de la siguiente manera:
<tipo>[ámbito opcional]: <descripción>
[cuerpo opcional]
[nota(s) al pie opcional(es)]
11.7.1. Tipos
-
fix
: un commit de tipo fix corrige un error en la base del código (se correlaciona con PATCH en el Versionado Semántico). -
feat
: un commit de tipo feat introduce una nueva funcionalidad en la base del código (se correlaciona con MINOR en el Versionado Semántico). -
tipos distintos a
fix:
yfeat:
están permitidos, por ejemplo (basados en la convención de Angular) que recomiendabuild:
,chore:
,ci:
,docs:
,style:
,refactor:
,perf:
,test:
, y otros.
Ejemplos
docs(changelog): update changelog to beta.5
fix(release): need to depend on latest rxjs and zone.js
The version in our package.json gets copied to the one we publish, and users need the latest of these.
Uso de Número de Issue
También es válido poner en el ámbito el número de issue relacionado.
docs(1085): added conventional commits.
11.8. Lectura Complementaria
-
https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/
-
https://about.gitlab.com/blog/2020/03/05/what-is-gitlab-flow/
-
https://www.atlassian.com/es/continuous-delivery/continuous-integration/trunk-based-development
-
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
-
https://docs.github.com/en/get-started/quickstart/github-flow
12. Frontend con Javascript
Las siglas DOM significan Document Object Model, o lo que es lo mismo, la estructura del documento HTML. Una página HTML está formada por múltiples etiquetas HTML, anidadas una dentro de otra, formando un árbol de etiquetas relacionadas entre sí, que se denomina árbol DOM (o simplemente DOM).
En Javascript, cuando nos referimos al DOM nos referimos a esta estructura de árbol, mediante la cuál podemos acceder a ella y modificar los elementos del HTML desde Javascript, añadiendo nuevas etiquetas, modificando o eliminando otras, cambiando sus atributos HTML, añadiendo clases, cambiando el contenido de texto, etc.
Si únicamente utilizamos HTML/CSS, solo podremos crear páginas «estáticas», es decir, páginas que no pueden mostrarse de una forma diferente dependiendo de acciones del usuario. Si añadimos Javascript, podremos crear páginas «dinámicas», es decir, aprovechar la potencia y flexibilidad que nos da un lenguaje de programación para crear documentos y páginas mucho más ricas, con una experiencia más completa y con las que se pueden automatizar un gran abanico de tareas y acciones.
12.1. Sintaxis Básica
(() => {
// Variables
let mivar = 1313;
// Constantes
const constante = 42;
const funcion = () => 42;
const funcion2 = function(parametro) {
return parametro;
};
console.log(constante);
console.log(funcion());
console.log(funcion2(42))
// Objetos
const objeto = {
valor: "este es otro valor",
funcion: (parametro) => {
return parametro;
}
};
objeto.clave = "Una nueva clave";
console.log(JSON.stringify(objeto));
// Transformacion de un String Json a Objeto
const json = JSON.parse(`
{"clave": "este es un valor"}
`);
console.log(json["clave"]);
// Creación de una clase
class Clase {
metodo(parametro) {
return parametro;
}
}
console.log((new Clase()).metodo(42));
})();
12.2. Función Auto ejecutable
Cuando necesitamos manipular el DOM desde la consola del navegador u otros contextos, se recomienda encapsular el código dentro de una función para evitar conflictos.
Una forma de realizar esto es utilizar una Función Auto Ejecutable que es invocada automáticamente luego de ser definida.
(() => {
// Código
})();
12.3. Funcional
(() => {
[1, 2, 3].forEach(item => console.log(item + 1));
console.log(
[3, 4, 5].map(item => item + 1)
);
console.log(
[6, 7, 8].reduce((acc, valor) => acc + valor, 0)
);
console.log(
[10, 11, 12].filter(number => number % 2 == 0)
);
})();
12.4. Manipulación del DOM
El DOM puede ser manipulado al buscar elementos
utilizando los atributos id
y class
(entre otros) del HTML.
Ejemplo buscando por id
<div id="mi-elemento">Cambiame</div>
(() => {
const elemento = document.getElementById("mi-elemento");
elemento.innerHTML = '<p>Nuevo HTML</p>';
})();
Ejemplo buscando por tipo de elemento
<div id="imagenes">
<img class="imagen" src="https://place-hold.it/300x200">
<img class="imagen" src="https://place-hold.it/300x300">
</div>
(() => {
const elementos = document.getElementsByTagName("img");
Array.from(elementos).forEach(elemento => {
elemento.src = "https://place-hold.it/400x400"
});
})();
12.5. Inspector del Navegador
Inspeccionar elementos es una característica de los navegadores web que permite ver y editar el código fuente de un sitio web, incluidos sus archivos HTML, CSS, JavaScript y multimedia. Cuando modificas el código fuente con la herramienta de inspección, los cambios se muestran en vivo dentro de la ventana del navegador.
13. El Lenguaje Elixir
Se recomienda seguir el laboratorio web de Elixir https://markm208.github.io/exbook/chapter1/01/index.html
y los capítulos del libro https://joyofelixir.com/
13.1. Valores
booleano = true
numero = 123_456
string = "Mi Cadena de Caracteres" <> "Concatenada"
atomo = :un_atomo
funcion = fn _ -> "Hola" end
mapa = %{valor: "hola"}
lista = [1, "dos", :tres]
IO.inspect("Imprimir en Terminal")
# Comentario
13.2. Módulos
Los módulos son definidos de la siguiente forma
defmodule MiModulo do
@constante "Esta constante no puede ser reasignada"
def mi_funcion_publica() do
"Función Pública"
end
defp mi_funcion_privada() do
"Función Privada"
end
end
13.3. Pattern Matching
Esta técnica propia de los lenguajes funcionales, se utiliza para buscar patrones y decidir qué hacer en cada momento.
Debemos pensar en el operador =
no como un signo igual típico de otros lenguajes,
sino como el que nos encontramos en una función matemática
del tipo x = a + 1
. Es decir que estamos diciendo que x
y a + 1
tienen el mismo valor.
# a = 1
# b = "elixir"
# c = "ninjas"
{a, b, c} = {1, "elixir", "ninjas"}
Enlaces
13.4. Pipe
La programación puede ser desordenada. De hecho tan desordenada que las llamadas de función pueden estar tan contenidas que sean difícil de entender.
Por ejemplo, toma en consideración las siguientes funciones anidadas:
foo(bar(baz(nueva_function(otra_function()))))
Aquí, pasamos el valor de otra_function/1
a nueva_function/1
, y de nueva_function/1
a baz/1
, baz/1
a bar/1
, y finalmente el resultado de bar/1
a foo/1
.
Elixir adopta un enfoque pragmático a este caos sintáctico al darnos el operador pipe.
El operador pipe que luce así |>
toma el resultado de una expresión, y se lo pasa a la siguiente.
Vamos a echar otro vistazo al código anterior reescrito con el operador pipe.
otra_function()
|> nueva_function()
|> baz()
|> bar()
|> foo()
El operador lleva el resultado de la izquierda, y lo pasa a la derecha.
Enlaces
13.5. Dependencias
Para instalar las dependencias debemos utilizar el comando
$ mix deps.get
Las dependencias están definidas en el archivo mix.exs
# Run "mix help deps" to learn about dependencies
defp deps do
[
# {:dep_from_hexpm, "~> 0.3.0"},
# {:dep_from_git, git: "https://github.com/elixir-lang/my_dep.git", tag: "0.1.0"},
]
end
13.6. Formateo
Para formatear automáticamente nuestro código se utiliza el comando
$ mix format
Esto permite estandarizar el estilo del código y no tener problemas al momento de programar en equipo.
13.7. Pruebas (Testing)
Para realizar pruebas se utiliza el comando
$ mix test
13.8. Pruebas Unitarias
Las pruebas unitarias consisten en aislar una parte del código y comprobar que funciona a la perfección. Son pequeños tests que validan el comportamiento de un objeto y la lógica. El unit testing suele realizarse durante la fase de desarrollo de aplicaciones de software o móviles. Normalmente las llevan a cabo los desarrolladores, aunque en la práctica, también pueden realizarlas los responsables de QA. Hay una especie de mito respecto a las pruebas unitarias. Algunos desarrolladores están convencidos de que son una pérdida de tiempo y las evitan buscando ahorrar tiempo. Nada más alejado de la realidad. Con ellas se detectan antes errores que, sin las pruebas unitarias, no se podrían detectar hasta fases más avanzadas como las pruebas de sistema, de integración e incluso en la beta. Realizar pruebas unitarias con regularidad supone, al final, un ahorro de tiempo y dinero.
Enlaces
13.9. Phoenix Framework
Si bien es posible crear backends con Elixir completamente
utilizando mix
y plug
. El framework más recomendado es Phoenix.
Phoenix es un framework de desarrollo web escrito en Elixir que implementa el patrón Model View Controller (MVC) del lado del servidor. Muchos de sus componentes y conceptos nos resultarán familiares a aquellos que tengamos experiencia en otros frameworks web como Ruby on Rails o Python con Django.
Phoenix ofrece lo mejor de ambos mundos: alta productividad de los desarrolladores y alto rendimiento de las aplicaciones. También tiene algunos giros nuevos e interesantes, como canales para implementar funciones en tiempo real y plantillas precompiladas para una velocidad increíble.
Enlaces
13.10. ¿Por qué utilizar Phoenix frente a las alternativas?
Hoy en día existen diversas alternativas para elaborar soluciones de backend. Entre las más populares encontramos a Nitrogen con Erlang, PHP con Laravel, Python con Django, Ruby con Rails, Java con Springboot y muchas otras con Javascript.
Si bien un proyecto puede ser exitoso, robusto y bien estructurado con cualquier tecnología. Lo ideal es siempre utilizar tecnologías que sean altamente cohesionadas y faciliten elaborar sistemas bien estructurados desde un comienzo, que cuenten con las protecciones necesarias de seguridad. Con estándares y documentación amplia que faciliten el aprendizaje de nuevos desarrolladores.
Phoenix cuenta con los más de treinta años de la máquina virtual de Erlang para su robustez y altos estándares de seguridad, además de la sintaxis amigable y moderna del lenguaje de programación Elixir.
Debido a la alta concurrencia de las necesidades actuales (con millones de dispositivos conectados a la vez), utilizar tecnologías que solucionen estos problemas de fábrica es un gran acierto.
El autor Sasa Juric en su charla "El alma de Elixir". Nos muestra por qué razón es una buena idea utilizar soluciones basadas en la máquina virtual de Erlang, ya que nos permite reducir enormemente la cantidad de dependencias de la solución, utilizando componentes que vienen de fábrica para resolver problemas comunes en sistemas distribuidos.
El simplificar nuestra estructura de servidores al utilizar una base sólida como la BEAM, nos da una reducción de la entropía (menor cantidad de componentes) y una reducción de costos significativa.
Un ejemplo es el caso de la empresa Pinterest donde uno de los sistemas que se ejecutaba en 200 servidores Python ahora se ejecuta en cuatro servidores Elixir. El efecto combinado de una mejor arquitectura y Elixir ahorró a Pinterest más de $2 millones por año en costos de servidor. Además, el rendimiento y la confiabilidad de los sistemas aumentaron a pesar de funcionar con mucho menos hardware. Cuando el sistema de notificaciones se ejecutaba en Java, estaba en 30 instancias c32.xl. Cuando se cambió a Elixir, podía ejecutarse en 15. A pesar de ejecutarse en menos hardware, los tiempos de respuesta se redujeron significativamente, al igual que los errores.
Un lenguaje que permite a las empresas ahorrar dinero mientras mejora la confiabilidad y el rendimiento parece una fantasía. Elixir puede demostrar este increíble resultado porque el lenguaje está construido sobre Erlang, una plataforma diseñada para software concurrente que debe permanecer en línea. -Los sitios de comercio y los productos SaaS son solo algunos ejemplos, la mayoría del software empresarial actual tiene este requisito. La historia de Elixir mejorando un producto mientras reduce costos se repite.
Enlaces
14. Aplicaciones Móviles
Las aplicaciones móviles son ejecutadas en los denominados "Teléfonos Inteligentes" o Smartphones. La industria de las aplicaciones móviles está dominada principalmente por dos sistemas operativos: Android (Google) e iOS (Apple). Aunque existen otros menores como Tizen (Samsung) y HarmonyOS (Hwuawei).
14.1. Comparación entre Android e iOS
Plataforma |
Precio cuenta Dev |
Lenguajes de Programación |
Tienda |
Comentario |
Android |
$20 USD (único) |
Kotlin, Java |
Playstore |
Popular en Latinoamérica y países donde no hay Apple Store oficial. |
iOS |
$100 USD (al año) |
Swift, Objective-C |
Appstore |
Popular en países donde existen Apple Store oficiales, debido a su más elevado precio. |
14.2. Tecnologías Nativas
-
Android utiliza los lenguajes de programación Kotlin y Java.
-
iOS utiliza los lenguajes de programación Swift y Objective-C.
14.3. Tecnologías Alternativas
En los últimos años nacieron varias formas nuevas de crear aplicaciones móviles. Enfocadas en reutilizar el código y reducir el esfuerzo del desarrollador necesario para dar vida a una aplicación. Se ha seleccionado algunas tecnologías diferentes: Onsen, NativeScript, React Native, Jasonelle, Elixir Desktop y LiveNative. Para permitir una comparación, aunque no es una lista exhaustiva.
14.3.1. Categorías
Entre los frameworks de desarrollo móvil nos encontramos con dos grandes categorías.
Frameworks Nativos
Son tecnologías que permiten compilar a nativo la aplicación (no utilizan un navegador web como base).
-
Aplicaciones hechas con Kotlin/Swift/C.
-
Aplicaciones hechas con frameworks de videojuegos (Godot, SDL, Unity, Unreal).
-
Aplicaciones que tras un proceso de compilación, ejecutan el código nativo (React Native, Native Script, LiveNative).
¿Cuándo usar?
La mayoría de las opciones utilizan o están inspiradas en tecnologías que surgieron de la web ( Javascript, CSS, HTML). Por lo tanto, en determinadas situaciones es mejor seguir con las tecnologías de desarrollador oficiales para Android o iOS. Algunas razones válidas son:
-
La organización invirtió mucho en Kotlin o Swift Developers.
-
Los desarrolladores son verdaderos expertos en Java, Kotlin, Objective-C o Swift. Tienen muchos años de experiencia y utilizar una de las nuevas tecnologías debería ser un proceso lento.
-
La organización ya tiene implementados procesos de pruebas, herramientas de integración continua, mejores prácticas y otras cosas. Adoptar estas nuevas tecnologías significa rehacer todo el proceso de definición de herramientas adaptadas a las nuevas tecnologías.
-
El uso de nuevas tecnologías debe ser sólo en proyectos experimentales o no críticos. Si no se toma con suficiente cuidado, la organización corre el riesgo de ralentizar la productividad y frustrar a los desarrolladores.
-
Si el cliente requiere algo hecho sólo con código nativo. Los requisitos sólo se pueden realizar con SDK oficiales.
Frameworks WebView
Los frameworks tipo WebView permiten crear aplicaciones utilizando las tecnologías web (HTML, JS, CSS). Básicamente son un navegador web que permite utilizar algunas APIs nativas a través de puentes creados con código nativo.
Son muy populares sobre todo si ya tienes una aplicación web y debes adaptarla a móvil, o para hacer prototipos rápidos.
En ésta categoría están.
-
Onsen
-
Ionic
-
Elixir Desktop
-
Jasonelle
¿Cuándo usar?
Útil para crear aplicaciones y prototipos rápidos. Algunos prototipos requerirán integrar herramientas nativas, la web no cuenta con todas las apis que tiene una opción nativa. La experiencia de usuario web (Web UX) es diferente a UX móvil nativo. Tener en cuenta que al diseñar interfaces y experiencias de usuario, especialmente cuando se utilizan entradas seleccionadas u otros componentes. La contraparte nativa podría ser más grande y podría romper el diseño original.
-
Pequeñas aplicaciones
-
Prototipos rápidos
-
Aplicaciones simples de línea de negocios (https://en.wikipedia.org/wiki/Line_of_business).
-
Aplicaciones que utilizan mucho formularios y gráficos para la entrada y presentación de datos.
14.3.2. ¿Cúal usar?
Si la organización está formada principalmente por desarrolladores web, utilizar Onsen o Jasonelle podría ser la primera opción para empezar a crear aplicaciones móviles.
Si usan React, entonces React Native podría ser la opción correcta. Si lo prefiere, puede elegir Angular Onsen y NativeScript.
Elixir Desktop y LiveNative son dos opciones muy buenas que permiten utilizar la potente tecnología de Elixir para el desarrollo de aplicaciones móviles. No solamente tendrás una aplicación móvil, si no también el backend completo, por lo que eligiendo la tecnologías de Elixir simplificarás en gran medida los componentes necesarios para tener una aplicación móvil robusta y preparada para el futuro.
Framework |
Web |
Categoría |
Comentario |
Jasonelle |
WebView + Javascript |
Es un envoltorio (wrapper) para una url y convertirla a aplicación. |
|
Onsen |
WebView + Javascript |
Puedes generar tu aplicación con HTML, CSS y JS. Alternativa a IONIC. |
|
Elixir Desktop |
WebView + Elixir |
Ejecuta un servidor web local con el framework Phoenix. |
|
Native Script |
Nativo + Typescript |
Permite crear aplicaciones nativas usando Typescript y ser un puente para otras tecnologías. |
|
React Native |
Nativo + Javascript |
Enfocado en generar aplicaciones para iOS y Android usando Javascript y el frontend framework React. |
|
LiveNative |
Nativo + Elixir |
Permite generar aplicaciones nativas conectándose a un servidor con Phoenix framework. |
Bibliografía
Una lista de recursos complementarios y referenciales.
-
[webdesignplayground] Paul McFedries. 'Web Design Playground: HTML & CSS The Interactive Way'. https://www.manning.com/books/web-design-playground. ISBN 978-1617294402.
-
[ Malcolm McDonald. 'Grokking Web Application Security'. https://www.manning.com/books/grokking-web-application-security. ISBN 978-1633438262.
-
[elixirinaction] Saša Jurić. 'Elixir in Action'. https://www.manning.com/books/elixir-in-action-third-edition. ISBN 978-1633438514.
-
[joyofelixir] Ryan Bigg. 'Joy of Elixir'. https://joyofelixir.com/.
-
[elixirpa] Stefan Wintermeyer. 'An Elixir, Phoenix and Ash Beginner’s Guide'. https://elixir-phoenix-ash.com.
-
[revolucionariosciber] Eden Medina. 'Revolucionarios cibernéticos. Tecnología y política en el Chile de Salvador Allende'. https://lom.cl/products/revolucionarios-ciberneticos-tecnologia-y-politica-en-el-chile-de-salvador-allende. ISBN 978-9560004352.
-
[tejiendolared] Tim Berners-Lee. 'Tejiendo la Red'. ISBN 84-323-1040-9.
-
[systemdesign] Alex Xu. 'System Design Interview: An Insider’s Guide'. ISBN 979-8664653403.