Nota. traducir: Este artículo, que se convirtió en un éxito en Medium, es una descripción general de los cambios clave (2010-2019) en el mundo de los lenguajes de programación y el ecosistema tecnológico asociado (con especial atención en Docker y Kubernetes). Su autora original es Cindy Sridharan, que se especializa en herramientas de desarrollo y sistemas distribuidos (en particular, escribió el libro "Distributed Systems Observability") y es bastante popular en Internet entre los especialistas de TI, especialmente interesados en el tema de la nube nativa.
Ahora que 2019 llega a su fin, quería compartir mis pensamientos sobre algunos de los avances e innovaciones tecnológicos más importantes de la última década. Además, intentaré mirar un poco hacia el futuro y esbozar los principales problemas y oportunidades de la próxima década.
Quiero dejar claro que en este artículo no cubro cambios en áreas como la ciencia de datos. (Ciencia de los datos), inteligencia artificial, ingeniería frontend, etc., ya que personalmente no tengo suficiente experiencia en ellos.
La tipificación contraataca
Una de las tendencias más positivas de la década de 2010 fue el resurgimiento de los lenguajes tipificados estáticamente. Sin embargo, estos lenguajes nunca desaparecieron (C++ y Java tienen demanda hoy en día; dominaron hace diez años), pero los lenguajes de tipado dinámico (dinámica) experimentaron un aumento significativo en popularidad después del surgimiento del movimiento Ruby on Rails en 2005. . Este crecimiento alcanzó su punto máximo en 2009 con el código abierto de Node.js, que hizo realidad el Javascript en el servidor.
Con el tiempo, los lenguajes dinámicos han perdido parte de su atractivo en el campo de la creación de software de servidor. El lenguaje Go, popularizado durante la revolución de los contenedores, parecía más adecuado para crear servidores de alto rendimiento y eficientes en recursos con procesamiento paralelo (con el que el propio creador de Node.js).
Rust, introducido en 2010, incluyó avances en en un intento de convertirse en un lenguaje seguro y mecanografiado. En la primera mitad de la década, la recepción de Rust por parte de la industria fue bastante tibia, pero su popularidad aumentó significativamente en la segunda mitad. Los casos de uso notables de Rust incluyen su uso para , (hablamos de ello en - aprox. trad.), uno de los primeros compiladores de WebAssembly de Fastly (ahora parte de bytecodealliance), etc. Con Microsoft considerando la posibilidad de reescribir algunas partes del sistema operativo Windows en Rust, es seguro decir que este lenguaje tiene un futuro brillante en la década de 2020.
Incluso los lenguajes dinámicos obtuvieron nuevas características como (tipos opcionales). Se implementaron por primera vez en TypeScript, un lenguaje que le permite crear código escrito y compilarlo en JavaScript. PHP, Ruby y Python tienen sus propios sistemas de escritura opcionales (, ), que se utilizan con éxito en .
Devolver SQL a NoSQL
NoSQL es otra tecnología que fue mucho más popular a principios de la década que al final. Creo que hay dos razones para esto.
En primer lugar, el modelo NoSQL, con su falta de esquema, transacciones y garantías de coherencia más débiles, resultó ser más difícil de implementar que el modelo SQL. EN con el título "Por qué debería preferir una coherencia fuerte siempre que sea posible" (Por qué debería elegir una consistencia fuerte, siempre que sea posible) Google escribe:
Una de las cosas que hemos aprendido en Google es que el código de la aplicación es más simple y el tiempo de desarrollo es más corto cuando los ingenieros pueden confiar en el almacenamiento existente para manejar transacciones complejas y mantener los datos en orden. Para citar la documentación original de Spanner, "Creemos que es mejor para los programadores lidiar con los problemas de rendimiento de las aplicaciones debido al abuso de transacciones a medida que surgen cuellos de botella, en lugar de tener en cuenta constantemente la ausencia de transacciones".
La segunda razón se debe al aumento de las bases de datos SQL distribuidas "escalables" (como и ) en el espacio de la nube pública, así como alternativas de código abierto como CockroachDB (estamos hablando de ella también - aprox. trad.), que resuelven muchos de los problemas técnicos que causaron que las bases de datos SQL tradicionales "no escalaran". Incluso MongoDB, que alguna vez fue el epítome del movimiento NoSQL, ahora es transacciones distribuidas.
Para situaciones que requieren lecturas y escrituras atómicas en múltiples documentos (en una o más colecciones), MongoDB admite transacciones de múltiples documentos. En el caso de transacciones distribuidas, las transacciones se pueden utilizar en múltiples operaciones, colecciones, bases de datos, documentos y fragmentos.
transmisión total
Apache Kafka es sin duda uno de los inventos más importantes de la última década. Su código fuente se abrió en enero de 2011 y, a lo largo de los años, Kafka ha revolucionado la forma en que las empresas trabajan con datos. Kafka se ha utilizado en todas las empresas para las que he trabajado, desde nuevas empresas hasta grandes corporaciones. Las garantías y los casos de uso que proporciona (pub-sub, transmisiones, arquitecturas basadas en eventos) se utilizan en una variedad de tareas, desde el almacenamiento de datos hasta el monitoreo y el análisis de transmisión, muy demandados en muchas áreas como finanzas, atención médica, sector público, comercio minorista, etc.
Integración Continua (y en menor medida Despliegue Continuo)
La Integración Continua no apareció en los últimos 10 años, pero durante la última década se ha extendido hasta tal punto, que se ha convertido en parte del flujo de trabajo estándar (ejecute pruebas en todas las solicitudes de extracción). Establecer GitHub como una plataforma para desarrollar y almacenar código y, lo que es más importante, desarrollar un flujo de trabajo basado en significa que ejecutar pruebas antes de aceptar una solicitud de extracción para dominar es единственный flujo de trabajo en desarrollo, familiar para los ingenieros que comenzaron sus carreras en los últimos diez años.
La implementación continua (implementar cada confirmación cuando llega al maestro) no está tan extendida como la integración continua. Sin embargo, con la gran cantidad de diferentes API en la nube para implementación, la creciente popularidad de plataformas como Kubernetes (que proporcionan una API estandarizada para implementaciones) y el surgimiento de herramientas multiplataforma y multinube como Spinnaker (construidas sobre las API estandarizadas). API), los procesos de implementación se han vuelto más automatizados, optimizados y, en general, más seguros.
contenedores
Los contenedores son quizás la tecnología más publicitada, publicitada e incomprendida de la década de 2010. Por otro lado, es una de las innovaciones más importantes de la década anterior. Parte de la razón de toda esta cacofonía radica en las señales contradictorias que recibimos de casi todas partes. Ahora que el revuelo se ha calmado un poco, algunas cosas se han vuelto más evidentes.
Los contenedores se han vuelto populares no porque sean la mejor manera de ejecutar una aplicación que satisfaga las necesidades de la comunidad global de desarrolladores. Los contenedores se hicieron populares porque encajaron con éxito en una solicitud de marketing de una determinada herramienta que resuelve un problema completamente diferente. Docker resultó ser fantástico una herramienta de desarrollo que resuelve el urgente problema de compatibilidad (“funciona en mi máquina”).
Más precisamente, la revolución se hizo imagen acoplable, porque resolvió el problema de la paridad entre entornos y proporcionó una verdadera portabilidad no sólo del archivo de la aplicación, sino también de todo su software y dependencias operativas. El hecho de que esta herramienta de alguna manera impulsó la popularidad de los “contenedores”, que son esencialmente un detalle de implementación de muy bajo nivel, sigue siendo para mí quizás el principal misterio de la última década.
Sin servidor
Apostaría a que la llegada de la informática "sin servidor" es incluso más importante que los contenedores porque realmente hace realidad el sueño de la informática bajo demanda. (On-demand). Durante los últimos cinco años, he visto cómo el enfoque sin servidor amplía gradualmente su alcance al agregar soporte para nuevos lenguajes y tiempos de ejecución. La aparición de productos como Azure Durable Functions parece ser el paso correcto hacia la implementación de funciones con estado (al mismo tiempo un paso decisivo relacionado con las limitaciones de FaaS). Observaré con interés cómo se desarrolla este nuevo paradigma en los próximos años.
Automatización
Quizás el mayor beneficiario de esta tendencia sea la comunidad de ingeniería de operaciones, ya que ha permitido que conceptos como infraestructura como código (IaC) se conviertan en realidad. Además, la pasión por la automatización ha coincidido con el surgimiento de la “cultura SRE”, que apunta a adoptar un enfoque de operaciones más centrado en el software.
APIficación universal
Otra característica interesante de la última década ha sido la APIificación de diversas tareas de desarrollo. Las API buenas y flexibles permiten al desarrollador crear flujos de trabajo y herramientas innovadores, que a su vez ayudan con el mantenimiento y mejoran la experiencia del usuario.
Además, la API-ficación es el primer paso hacia la SaaS-ficación de alguna funcionalidad o herramienta. Esta tendencia también coincidió con el aumento de la popularidad de los microservicios: SaaS se ha convertido en un servicio más al que se puede acceder a través de API. Ahora hay muchas herramientas SaaS y FOSS disponibles en áreas como monitoreo, pagos, equilibrio de carga, integración continua, alertas y cambio de funciones. (marcación de funciones), CDN, ingeniería de tráfico (por ejemplo, DNS), etc., que han florecido en la última década.
observabilidad
Vale la pena señalar que hoy tenemos acceso a mucho más avanzado herramientas para monitorear y diagnosticar el comportamiento de las aplicaciones que nunca antes. El sistema de seguimiento Prometheus, que recibió el estatus de código abierto en 2015, quizás pueda denominarse lo mejor sistema de seguimiento de aquellos con los que he trabajado. No es perfecto, pero una cantidad significativa de cosas se implementan exactamente de la manera correcta (por ejemplo, soporte para mediciones [dimensionalidad] en el caso de métricas).
El rastreo distribuido fue otra tecnología que se generalizó en la década de 2010, gracias a iniciativas como OpenTracing (y su sucesor OpenTelemetry). Aunque el rastreo sigue siendo bastante difícil de aplicar, algunos de los últimos avances dan esperanza de que desbloquearemos su verdadero potencial en la década de 2020. (Nota: Lea también en nuestro blog la traducción del artículo “"del mismo autor.)
Mirando hacia el futuro
Desafortunadamente, hay muchos puntos débiles que esperan solución en la próxima década. Aquí están mis pensamientos sobre ellos y algunas ideas potenciales sobre cómo deshacerse de ellos.
Resolviendo el problema de la ley de Moore
El fin de la ley de escala de Dennard y el retraso con respecto a la ley de Moore requieren nuevas innovaciones. John Hennessy en explica por qué los adictos problemáticos (dominio específico) Arquitecturas como TPU pueden ser una de las soluciones al problema del retraso con respecto a la Ley de Moore. Conjuntos de herramientas como de Google ya parecen ser un buen paso adelante en esta dirección:
Los compiladores deben admitir nuevas aplicaciones, trasladarse fácilmente a nuevo hardware, vincular múltiples capas de abstracción que van desde lenguajes dinámicos administrados hasta aceleradores vectoriales y dispositivos de almacenamiento controlados por software, al tiempo que proporcionan conmutadores de alto nivel para el ajuste automático, proporcionando solo- en funcionalidad: tiempo, diagnóstico y distribución de información de depuración sobre el funcionamiento y rendimiento de los sistemas en toda la pila, mientras que en la mayoría de los casos proporciona un rendimiento razonablemente cercano al ensamblador escrito a mano. Tenemos la intención de compartir nuestra visión, progreso y planes para el desarrollo y la disponibilidad pública de dicha infraestructura de compilación.
CI / CD
Si bien el auge de la CI se ha convertido en una de las tendencias más importantes de la década de 2010, Jenkins sigue siendo el estándar de oro para la CI.
Este espacio necesita urgentemente innovación en las siguientes áreas:
- interfaz de usuario (DSL para codificar especificaciones de prueba);
- detalles de implementación que la harán verdaderamente escalable y rápida;
- integración con varios entornos (puesta en escena, producción, etc.) para implementar formas de prueba más avanzadas;
- pruebas e implementación continuas.
Herramientas de desarrollo
Como industria, hemos comenzado a crear software cada vez más complejo e impresionante. Sin embargo, cuando se trata de nuestras propias herramientas, la situación podría ser mucho mejor.
La edición colaborativa y remota (a través de ssh) ganó cierta popularidad, pero nunca se convirtió en la nueva forma estándar de desarrollo. Si usted, como yo, rechaza la idea misma de necesidad una conexión permanente a Internet solo para poder programar, entonces es poco probable que trabajar a través de ssh en una máquina remota sea adecuado para usted.
Los entornos de desarrollo local, especialmente para los ingenieros que trabajan en grandes arquitecturas orientadas a servicios, siguen siendo un desafío. Algunos proyectos están intentando resolver esto y me interesaría saber cómo sería la UX más ergonómica para un caso de uso determinado.
También sería interesante ampliar el concepto de "entornos portátiles" a otras áreas de desarrollo como la reproducción de errores (o ) que ocurren bajo ciertas condiciones o entornos.
También me gustaría ver más innovación en áreas como búsqueda de código semántico y sensible al contexto, herramientas para correlacionar incidentes de producción con partes específicas del código base, etc.
Computación (el futuro de PaaS)
Tras el revuelo en torno a los contenedores y los sistemas sin servidor en la década de 2010, la gama de soluciones en el espacio de la nube pública se ha ampliado significativamente en los últimos años.
Esto plantea varias preguntas interesantes. En primer lugar, la lista de opciones disponibles en la nube pública crece constantemente. Los proveedores de servicios en la nube tienen el personal y los recursos para mantenerse al día con los últimos desarrollos en el mundo del código abierto y lanzar productos como "pods sin servidor" (sospecho que simplemente haciendo que sus propios tiempos de ejecución de FaaS sean compatibles con OCI) u otras cosas similares.
Sólo se puede envidiar a quienes utilizan estas soluciones en la nube. En teoría, las ofertas de nube de Kubernetes (GKE, EKS, EKS en Fargate, etc.) proporcionan API independientes del proveedor de nube para ejecutar cargas de trabajo. Si utilizas productos similares (ECS, Fargate, Google Cloud Run, etc.), probablemente ya estés aprovechando las funciones más interesantes que ofrece el proveedor del servicio. Además, a medida que surjan nuevos productos o paradigmas informáticos, es probable que la migración sea sencilla y sin estrés.
Teniendo en cuenta lo rápido que está evolucionando la gama de este tipo de soluciones (me sorprendería mucho si no aparecen un par de opciones nuevas en un futuro próximo), los pequeños equipos de "plataforma" (equipos asociados con la infraestructura y responsables de crear plataformas locales para empresas que ejecutan cargas de trabajo) será increíblemente difícil competir en términos de funcionalidad, facilidad de uso y confiabilidad general. La década de 2010 vio a Kubernetes como una herramienta para construir PaaS (plataforma como servicio), por lo que me parece completamente inútil construir una plataforma interna sobre Kubernetes que ofrezca las mismas opciones, simplicidad y libertad disponibles en el público. espacio en la nube. Enmarcar PaaS basada en contenedores como una “estrategia de Kubernetes” equivale a evitar deliberadamente las capacidades más innovadoras de la nube.
Si miras los disponibles hoy capacidades informáticas, resulta obvio que crear su propio PaaS basado únicamente en Kubernetes equivale a arrinconarse (no es un enfoque muy progresista, ¿eh?). Incluso si alguien decide construir una PaaS en contenedores en Kubernetes hoy, en un par de años parecerá obsoleta en comparación con las capacidades de la nube. Aunque Kubernetes comenzó como un proyecto de código abierto, su antecesor e inspiración es una herramienta interna de Google. Sin embargo, se desarrolló originalmente a principios o mediados de la década de 2000, cuando el panorama informático era completamente diferente.
Además, en un sentido muy amplio, las empresas no tienen que convertirse en expertas en administrar un clúster de Kubernetes, ni construyen ni mantienen sus propios centros de datos. Proporcionar una base informática confiable es un desafío fundamental proveedores de servicios en la nube.
Finalmente, siento que hemos retrocedido un poco como industria en términos de experiencia de interacción (). Heroku se lanzó en 2007 y sigue siendo uno de los más fácil de usar plataformas. No se puede negar que Kubernetes es mucho más potente, extensible y programable, pero extraño lo fácil que es comenzar e implementar en Heroku. Para utilizar esta plataforma, sólo necesitas conocer Git.
Todo esto me lleva a la siguiente conclusión: necesitamos mejores abstracciones de mayor nivel para funcionar (esto es especialmente cierto para abstracciones de más alto nivel).
La API adecuada al más alto nivel
Docker es un gran ejemplo de la necesidad de una mejor separación de preocupaciones al mismo tiempo. correcta implementación de la API de más alto nivel.
El problema con Docker es que (al menos) inicialmente los objetivos del proyecto eran demasiado amplios: todo para resolver el problema de compatibilidad (“funciona en mi máquina”) utilizando tecnología de contenedores. Docker era un formato de imagen, un tiempo de ejecución con su propia red virtual, una herramienta CLI, un demonio que se ejecutaba como root y mucho más. En cualquier caso, el intercambio de mensajes fue más confuso, sin mencionar las "máquinas virtuales livianas", cgroups, espacios de nombres, numerosos problemas y características de seguridad mezclados con el llamado de marketing de "construir, entregar y ejecutar cualquier aplicación en cualquier lugar".
Como ocurre con todas las buenas abstracciones, se necesita tiempo (y experiencia y dolor) para descomponer varios problemas en capas lógicas que puedan combinarse entre sí. Desafortunadamente, antes de que Docker pudiera alcanzar una madurez similar, Kubernetes entró en escena. Monopolizó tanto el ciclo de publicidad que ahora todos intentaban mantenerse al día con los cambios en el ecosistema de Kubernetes, y el ecosistema de contenedores adquirió un estatus secundario.
Kubernetes comparte muchos de los mismos problemas que Docker. Por toda la charla sobre abstracción genial y componible, separar diferentes tareas en capas no muy bien encapsulado. En esencia, es un orquestador de contenedores que ejecuta contenedores en un grupo de máquinas diferentes. Esta es una tarea de nivel bastante bajo, aplicable sólo a los ingenieros que operan el clúster. Por otro lado, Kubernetes también abstracción del más alto nivel, una herramienta CLI con la que los usuarios interactúan a través de YAML.
Docker era (y sigue siendo) Frío herramienta de desarrollo, a pesar de todas sus deficiencias. En un intento por mantenerse al día con todas las "liebres" a la vez, sus desarrolladores lograron implementar correctamente abstracción al más alto nivel. Por abstracción al más alto nivel me refiero subconjunto funcionalidad que realmente interesaba al público objetivo (en este caso, desarrolladores que pasaban la mayor parte de su tiempo en sus entornos de desarrollo locales) y que funcionó muy bien desde el primer momento..
Utilidad Dockerfile y CLI docker debería ser un ejemplo de cómo crear una buena "experiencia de usuario del más alto nivel". Un desarrollador normal puede empezar a trabajar con Docker sin saber nada sobre las complejidades. Implementaciones que contribuyen a la experiencia operativa.como espacios de nombres, cgroups, límites de memoria y CPU, etc. En última instancia, escribir un Dockerfile no es muy diferente de escribir un script de Shell.
Kubernetes está destinado a diferentes grupos objetivo:
- administradores de clústeres;
- ingenieros de software que trabajan en cuestiones de infraestructura, ampliando las capacidades de Kubernetes y creando plataformas basadas en él;
- usuarios finales que interactúan con Kubernetes a través de
kubectl.
El enfoque de Kubernetes de "una API para todos" presenta una "montaña de complejidad" insuficientemente encapsulada y sin orientación sobre cómo escalarla. Todo esto conduce a una trayectoria de aprendizaje injustificadamente prolongada. Cómo Adam Jacob, “Docker aportó una experiencia de usuario transformadora que nunca ha sido superada. Pregúntele a cualquiera que use un K8 si desearía que funcionara como el primero. docker run. La respuesta será sí":
Yo diría que la mayor parte de la tecnología de infraestructura actual es de nivel demasiado bajo (y, por lo tanto, se considera "demasiado compleja"). Kubernetes se implementa a un nivel bastante bajo. Seguimiento distribuido en su (muchos tramos unidos para formar una vista de seguimiento) también se implementa a un nivel demasiado bajo. Las herramientas de desarrollo que implementan las “abstracciones de más alto nivel” tienden a ser las más exitosas. Esta conclusión es cierta en un sorprendente número de casos (si la tecnología es demasiado compleja o difícil de usar, entonces aún no se ha descubierto la “API/UI de más alto nivel” para esa tecnología).
En este momento, el ecosistema nativo de la nube es confuso debido a su enfoque de bajo nivel. Como industria, debemos innovar, experimentar y educar sobre cómo es el nivel correcto de “máxima y más alta abstracción”.
Comercio minorista
En la década de 2010, la experiencia del comercio minorista digital se mantuvo prácticamente sin cambios. Por un lado, la facilidad de las compras en línea debería haber afectado a las tiendas minoristas tradicionales; por otro lado, las compras en línea se han mantenido prácticamente sin cambios en una década.
Si bien no tengo ideas específicas sobre cómo evolucionará esta industria durante la próxima década, me sentiría muy decepcionado si en 2030 compramos de la misma manera que lo hacemos en 2020.
Periodismo
Estoy cada vez más desilusionado con el estado del periodismo global. Cada vez es más difícil encontrar fuentes de noticias imparciales que informen de manera objetiva y meticulosa. Muy a menudo la línea entre las noticias en sí y las opiniones sobre ellas es borrosa. Por regla general, la información se presenta de forma sesgada. Esto es especialmente cierto en algunos países donde históricamente no ha habido separación entre noticias y opinión. En un artículo reciente publicado después de las últimas elecciones generales del Reino Unido, Alan Rusbridger, ex editor de The Guardian, :
El punto principal es que durante muchos años miré los periódicos estadounidenses y sentí pena por mis colegas allí, que eran los únicos responsables de las noticias, dejando los comentarios a personas completamente diferentes. Sin embargo, con el tiempo, la lástima se convirtió en envidia. Ahora creo que todos los periódicos nacionales británicos deberían separar su responsabilidad por las noticias de su responsabilidad por los comentarios. Desafortunadamente, al lector medio (especialmente a los lectores en línea) le resulta demasiado difícil discernir la diferencia.
Dada la reputación bastante dudosa de Silicon Valley en materia de ética, nunca confiaría en la tecnología para "revolucionar" el periodismo. Dicho esto, yo (y muchos de mis amigos) estaríamos contentos si hubiera una fuente de noticias imparcial, desinteresada y confiable. Si bien no tengo idea de cómo sería una plataforma de este tipo, estoy seguro de que en una era en la que la verdad es cada vez más difícil de discernir, la necesidad de un periodismo honesto es mayor que nunca.
Redes Sociales
Las redes sociales y las plataformas de noticias comunitarias son la principal fuente de información para muchas personas en todo el mundo, y la falta de precisión y la renuencia de algunas plataformas a realizar incluso una verificación básica de hechos ha tenido consecuencias desastrosas como genocidio, interferencia electoral y más. .
Las redes sociales son también la herramienta mediática más poderosa que jamás haya existido. Cambiaron radicalmente la práctica política. Cambiaron la publicidad. Cambiaron la cultura pop (por ejemplo, la principal contribución al desarrollo de la llamada cultura de la cancelación). [culturas del ostracismo - aprox. traducción] las redes sociales contribuyen). Los críticos argumentan que las redes sociales han demostrado ser un terreno fértil para cambios rápidos y caprichosos en los valores morales, pero también han brindado a miembros de grupos marginados la oportunidad de organizarse como nunca antes habían tenido. En esencia, las redes sociales han cambiado la forma en que las personas se comunican y se expresan en el siglo XXI.
Sin embargo, también creo que las redes sociales sacan a relucir los peores impulsos humanos. La consideración y la consideración a menudo se descuidan en favor de la popularidad, y resulta casi imposible expresar un desacuerdo razonado con ciertas opiniones y posiciones. La polarización a menudo se sale de control, lo que da como resultado que el público simplemente no escuche las opiniones individuales, mientras que los absolutistas controlan las cuestiones de etiqueta y aceptabilidad en línea.
Me pregunto si es posible crear una plataforma "mejor" que promueva debates de mejor calidad. Después de todo, es lo que impulsa el “compromiso” lo que a menudo genera el principal beneficio para estas plataformas. Cómo Kara Swisher en el New York Times:
Es posible desarrollar interacciones digitales sin provocar odio e intolerancia. La razón por la que la mayoría de los sitios de redes sociales parecen tan tóxicos es porque fueron creados para la velocidad, la viralidad y la atención, más que para el contenido y la precisión.
Sería realmente desafortunado que, en un par de décadas, el único legado de las redes sociales fuera la erosión de los matices y la idoneidad en el discurso público.
PD del traductor
Lea también en nuestro blog:
- «";
- «";
- «";
- «".
Fuente: habr.com