Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3073.html
Весь этот год мы в компании «Флант» активно переводили на Kubernetes проекты заказчиков, сильно различающихся как по масштабам, так и по технологиям. На данный момент (сентябрь 2017) у нас в Kubernetes (в production) функционируют 13 проектов, в состав которых входят более 130 различных приложений, написанных на 8 языках программирования: .NET, Erlang, Go, Java, Node.js, PHP, Python и Ruby. В этих проектах задействовано множество инфраструктурных компонентов, таких как Cassandra, Ceph, Firebird, Memcached, MongoDB, MySQL, NATS.io, NGINX, PostgreSQL, RabbitMQ, Redis, RethinkDB, Sphinx, SQLite и других. Мы поделимся обширным опытом, полученным в результате выстраивания CI/CD для таких приложений.
...
Лучшие практики CI/CD с Kubernetes и GitLab / Дмитрий Столяров (Флант)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 14:00
Тезисы:
http://www.highload.ru/2017/abstracts/3073.html
Весь этот год мы в компании «Флант» активно переводили на Kubernetes проекты заказчиков, сильно различающихся как по масштабам, так и по технологиям. На данный момент (сентябрь 2017) у нас в Kubernetes (в production) функционируют 13 проектов, в состав которых входят более 130 различных приложений, написанных на 8 языках программирования: .NET, Erlang, Go, Java, Node.js, PHP, Python и Ruby. В этих проектах задействовано множество инфраструктурных компонентов, таких как Cassandra, Ceph, Firebird, Memcached, MongoDB, MySQL, NATS.io, NGINX, PostgreSQL, RabbitMQ, Redis, RethinkDB, Sphinx, SQLite и других. Мы поделимся обширным опытом, полученным в результате выстраивания CI/CD для таких приложений.
...
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
NoSQL — это слово громко "жужжит".
К сожалению, оно при этом ничего не означает. Это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы.
На этом доклад можно было бы и закончить. Если бы мы не знали достоверно, что на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.
Попробуем еще раз.
NoSQL — это именно декларация отказа от некоторых паттернов.
- От чего именно придется отказаться? Упомянутые паттерны так живучи совсем не случайно.
- Как это ударит по проекту? Не сомневайтесь, оно ударит, в этом мире нет ни серебряных пуль, ни бесплатного сыра.
- Какими свойствами должен обладать проект, чтобы внедрение NoSQL СУБД принесло ему пользу? Избегать NoSQL — это не трусость, это осторожность.
- Каковы сильные стороны NoSQL СУБД, и в чем профит? Выбор NoSQL — это всегда выбор в пользу меньшего зла.
- Как выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES [currently >225], и даже просто прочесть его — тяжелая работа.
- Почему реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra? Да, это провокационный вопрос, но на него есть not-so-provocative ответ.
- С какими проблемами сталкиваются разработчики и администраторы при эксплуатации "тяжелой" NoSQL базы? К сожалению, большая часть этих проблем создается именно присутствием NoSQL.
- Что можно делать с NoSQL СУБД и чего нельзя? На какие параметры производительности и отказоустойчивости можно рассчитывать? В чем особенности выбора "железа" для NoSQL?
- И в чем, все-таки, profit?
На эти и некоторые другие, связанные с этими, вопросы автор намерен дать ответ в своем докладе.
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Григорий Петров "WebRTC в мобильных приложениях при помощи React Native"IT Event
Последние несколько лет в индустрии активно развивается WebRTC — технология, которая позволяет делать голосовые и видеозвонки прямо из браузеров. Но мало кто знает, что эта же технология может быть использована в нативных мобильных приложениях и основанных на них SDK. В своем докладе я хочу рассказать про опыт заворачивания существующих Android и iOS SDK в React Native:
— Как поддерживать несколько разных архитектур
— Как работать с нативными виджетами, такими как «вывод видео»
— Синхронизация event loop между C-реализацией и — JavaScript движком React Native
— Планы на будущее: React Native WebRTC
Слайды с одноименного доклада на IT Global Meetup 2015, прошедшего в Санкт-Петербурге 6 июля.
Тезисы:
* Контроль за качеством кода - это необходимая процедура при работе нескольких человек в одной команде над продуктом из более чем сотни строк. Зачем это нужно? Каждый пишет код по-своему, ожидает понимания от остальных участников команды, но в жизни этого не происходит.
* Недостатки разнобоя в стиле написанного кода: увеличивается время ревью, усложняется внесение правок кем-либо кроме автора кода, увеличивается вероятность пропустить глазами ошибку.
* Основные шаги к решению этой проблемы: создание единого свода правил по оформлению кода (style guide), согласование процедуры разрешения конфликтных ситуаций относительно разночтений этих правил, устранение человеческого фактора в процессе оценки через автоматизацию.
* Что из экосистемы Питона может помочь? При составлении style guide можно взять за основу PEP8 и PEP257, дополнив их принятыми в команде конвенциями (какие кавычки использовать для строк и докстрингов, и т.д. и т.п.). Автоматизировать проверки можно как с помощью уже готовых утилит (pep8, flake8, pylint), так и написав свои с помощью встроенного в язык инструментария (модули ast, tokenizer, сторонние библиотеки для работы с кодом).
* Где производить проверки? Есть несколько возможных этапов:
- IDE разработчика
- Локальная VCS (working copy)
- Общая VCS
- Сервер Continous Integration.
В идеале проверки должны быть на каждом этапе, но при этом как можно меньше затруднять обычный рабочий процесс. Здесь стоит задуматься, какая комбинация из этих этапов лучше всего впишется в стиль разработчки команды.
* Если же нет достаточных ресурсов или проект находится
"Инструментарий разработчика iOS: Xcode, AppCode и сторонние инструменты". Ма...Yandex
Выбор языка для разработки под iOS не ограничен Objective-C — всё зависит от конкретных задач. Но даже если код пишется на Objective-C, у разработчика есть и другие инструменты, кроме Xcode, способные облегчить жизнь. Есть сторонние тестовые фреймворки, менеджеры зависимостей, браузеры документации и, конечно, альтернативные IDE — например, AppCode.
В докладе я расскажу, почему в JetBrains создали собственную IDE для Objective-C, а не просто плагин к Xcode. Обсудим, чем AppCode отличается от Xcode, и как мы реализовали интеграцию с этой средой. А также поговорим о возникавших сложностях и планах по развитию интеграции и всего продукта.
"Инструментарий разработчика iOS: Xcode, AppCode и сторонние инструменты". Ма...Yandex
Выбор языка для разработки под iOS не ограничен Objective-C — всё зависит от конкретных задач. Но даже если код пишется на Objective-C, у разработчика есть и другие инструменты, кроме Xcode, способные облегчить жизнь. Есть сторонние тестовые фреймворки, менеджеры зависимостей, браузеры документации и, конечно, альтернативные IDE — например, AppCode.
В докладе я расскажу, почему в JetBrains создали собственную IDE для Objective-C, а не просто плагин к Xcode. Обсудим, чем AppCode отличается от Xcode, и как мы реализовали интеграцию с этой средой. А также поговорим о возникавших сложностях и планах по развитию интеграции и всего продукта.
TК°Conf. Организация разработки Frontend. Виталий Слободин.TKConf
Расскажу об организации процесса разработки Frontend в единый конвейер, чтобы увеличить скорость и минимизировать затраты с рисками.
Как организовать верстку макета по фантастичному макету дизайнера при этом не вогнав в когнитивный диссонанс результатом на Bootstrap.
Каким образом объединить воинствующие стороны: Frontend, Backend и дизайнеров.
Андрей Сибирёв "Ваше собственное облако — война за независимость"Yandex
Сегодня всё больше и больше компаний решаются на перевод своей инфраструктуры и сервисов в облака. Некоторые даже начинают строить свой бизнес, не имея ни единого собственного сервера для обработки или хранения пользовательских данных, и при этом становятся лидерами в своих сегментах рынка.
Но, несмотря на очевидные преимущества этого подхода, не всех устраивает перспектива быть привязанными к конкретному поставщику облачных услуг. В докладе рассказывается об основных тенденциях в современном «облакостроении», о свободе и гибкости и, самое главное, представляется наша открытая облачная платформа.
SECON'2016. Бартунов Олег, Карьера в Open SourceSECON
Я расскажу про то, как устроен современный Open Source на примере проекта PostgreSQL и про те возможности, которые дает Open Source разработчику, в частности, в реализации себя как творческой личности и карьерного роста, а также достижения свободы и независимости. Open Source в условиях цифрового равенства позволяет разработчику жить и работать в привычных условиях без обязательного перемещения в неудобный для жизни мегаполис, и при этом быть членом большого международного сообщества, принимать участие в его жизни и влиять на развитие проекта.
RTB и его проблематика должны быть знакомы участникам конференции - мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
При первом подходе к снаряду задача выглядит довольно простой: вот запрос с критериями, вот база данных с ответами - выбирай по индексу и отвечай.
На самом деле все несколько сложнее. Начать с того, что некоторые критерии отбора - негативные. Затем мы имеем дело с выборкой по десятку индексов, каждый из которых обладает низкой cardinality. И, наконец, мы имеем дело с большими объемами: около 10М строк в исходных данных, около 10К строк в финальной выборке. Ах, нет, еще финальная выборка должна быть отсортирована по приоритету! И надо не забыть про атомарные блокировку и списание средств...
От идеи прототипа на perl пришлось отказаться еще на этапе постановки задачи :)
Итак, мы имеем задачу с интенсивным IO, высокой нагрузкой, высокими скоростями, сложными структурами данных и эвристическими алгоритмами.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие - нет, будет рассказано в докладе.
Также в докладе будет рассказано о том, как сортировка была заменена случайной выборкой, и чем пришлось заплатить за то, чтобы эта замена оказалась равноценной.
Будет показано, почему мы наплевательски отнеслись к гипотетической потере 20% возможностей поучаствовать в аукционе, и почему реальный процент потерь много ниже.
Будет раскрыта роль СУБД MySQL в этом проекте, со всем блеском высокой производительности и нищетой отказоустойчивости.
Вопросы геотаргетинга, использования PostGIS и кэширования результатов поиска региона по координатам будут затронуты вскользь, как неоднократно обсуждавшиеся на этой и подобных конференциях.
А вот анатомия производительности приложения на Go будет рассмотрена подробнейшим образом - с графиками и числами.
Также подробно будут рассмотрены наши победы и поражения в борьбе со статис
RTB DSP на языке Go укрощение buzzwords / Даниил Подольский (Qmobi.Com)Ontico
RTB и его проблематика должны быть знакомы участникам конференции — мало кто сегодня не слышал об этом способе получить много krps с жесткими ограничениями на время генерации ответа.
Вот и компания Qmobi решила поучаствовать в этой гонке и отхватить свой кусок пирога под названием “рынок мобильной рекламы”.
Анализ имеющихся вариантов показал, что Go должен прекрасно подойти для этой задачи. О том, на основании каких соображений мы сделали такой вывод, и какие из этих соображений прошли проверку практикой, а какие — нет, будет рассказано в докладе.
От экспериментального программирования к промышленному: путь длиной в 10 летPositive Hack Days
Разработка наукоемкого программного обеспечения отличается тем, что нет ни четкой постановки задачи, ни понимания, что получится в результате. Однако даже этом надо программировать то, что надо, и как надо. Докладчик расскажет о том, как ее команда успешно разработала и вывела в промышленную эксплуатацию несколько наукоемких продуктов, пройдя непростой путь от эксперимента, результатом которого был прототип, до промышленных версий, которые успешно продаются как на российском, так и на зарубежном рынках. Этот путь был насыщен сложностями и качественными управленческими решениями, которыми поделится докладчик
2. Несколько слов о себе
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 2 / 53
• Главный инженер в Git in Sky
• Преподаватель в avalon.ru
• Researcher @ ISST Lab, ITMO
• Координатор встреч
DevOps-инженеров в Петербурге
• Пишу код
3. Слово «современные»
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 3 / 53
Что изображено на картинке?
(Мы будем говорить о вещах, придуманных 30 и более лет назад)
4. Немного истории
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 4 / 53
Носитель информации 30 лет назад
(Емкость примерно 200 килобайт)
5. ALGOL-60 и далее
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 5 / 53
Структурное и
процедурное
программирование
6. Корень всех зол (нет, не goto)
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 6 / 53
Как C-программист
под DSP пишет на C#?
В C# нет goto, но это не беда!
7. Зачем нужно OOP?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 7 / 53
• Инкапсуляция, наследование,
полиморфизм!
• Пенсия Гради Буча
8. Зачем на самом деле OOP?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 8 / 53
• Инкапсуляция, наследование,
полиморфизм!
• Пенсия Гради Буча
• Кошелек Миллера (спасибо Григорию
Петрову)
• Закон Деметры
• SOLID
10. SOLID
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 10 / 53
• Single responsibility principle
• Open/closed principle
11. SOLID
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 11 / 53
• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
12. SOLID
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 12 / 53
• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
13. SOLID
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 13 / 53
• Single responsibility principle
• Open/closed principle
• Liskov substitution principle
• Interface segregation principle
• Dependency inversion principle
14. Что-то пошло не так
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 14 / 53
Objects have failed* (OOPSLA 2002)
* на самом деле нет
15. 2002+15
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 15 / 53
Python - lingua franca индустрии
В Python есть всё
16. В Python есть всё
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 16 / 53
Зачем тогда что-то еще?
17. Отнять и поделить
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 17 / 53
Почему не декриминализуют легкие
наркотики?
18. Хороший Язык Будущего
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 18 / 53
• Строгая типизация (PHP и JS - плохие)
19. Хороший Язык Будущего
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 19 / 53
• Строгая типизация (PHP и JS - плохие)
• (Опциональная) статическая
типизация
20. Опциональная типизация
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 20 / 53
• PHP: type declarations, 5.0 => 7.0
• Python: type hints, PEP-484
• Python: mypy
22. Статические анализаторы
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 22 / 53
• mypy - статический анализатор кода
• статический анализатор работает до
запуска программы
23. Статические анализаторы
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 23 / 53
• mypy - статический анализатор кода
• статический анализатор работает до
запуска программы
• статический анализатор обобщает
идею статической типизации
24. Анализаторы разных языков
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 24 / 53
• Ruby: RuboCop
• Perl: Perl::Critic
• Python: Coala, Pylama, mypy
• PHP: PHPLint, PHP Mess Detector
25. Static Analysis Symposium
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 25 / 53
• Научная конференция
• Проходила уже 23 раза
• 23 сборника статей примерно по 400
страниц
26. Хороший Язык Будущего
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 26 / 53
• Строгая типизация (PHP и JS - плохие)
• (Опциональная) статическая
типизация
• Package/vendoring manager
27. Package managers
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 27 / 53
• PHP: Composer
• Python: pip
• Perl: cpanminus
• Ruby: bundler
28. Хороший Язык Будущего
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 28 / 53
• Строгая типизация (PHP и JS - плохие)
• (Опциональная) статическая
типизация
• Package/vendoring manager
29. Хороший Язык Будущего
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 29 / 53
• Строгая типизация (PHP и JS - плохие)
• (Опциональная) статическая
типизация
• Package/vendoring manager
• Метапрограммирование
30. Хороший Язык Будущего
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 30 / 53
• Строгая типизация (PHP и JS - плохие)
• (Опциональная) статическая
типизация
• Package/vendoring manager
• Метапрограммирование
• Иммутабельность
31. Хороший Язык Будущего
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 31 / 53
• Строгая типизация (PHP и JS - плохие)
• (Опциональная) статическая
типизация
• Package/vendoring manager
• Метапрограммирование
• Иммутабельность
• Null-safety
35. Сферический в вакууме
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 35 / 53
• Языку нужна среда исполнения
36. Сферический в вакууме
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 36 / 53
• Языку нужна среда исполнения
• JVM
37. Сферический в вакууме
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 37 / 53
• Языку нужна среда исполнения
• JVM
• V8
38. Сферический в вакууме
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 38 / 53
• Языку нужна среда исполнения
• JVM
• V8
• BEAM
39. Сферический в вакууме
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 39 / 53
• Языку нужна среда исполнения
• JVM
• V8
• BEAM
• Golang runtime (not a VM, but...)
40. A quest for my next PL
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 40 / 53
https://goo.gl/MS1UfB
Не надо всматриваться в скриншот сейчас!
42. Почему не Golang?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 42 / 53
• Очень простой: 25 ключевых слов
43. Почему не Golang?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 43 / 53
• Очень простой: 25 ключевых слов
• Нет метапрограммирования
44. Почему не Golang?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 44 / 53
• Очень простой: 25 ключевых слов
• Нет метапрограммирования
• Нет иммутабельности
45. Почему не Golang?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 45 / 53
• Очень простой: 25 ключевых слов
• Нет метапрограммирования
• Нет иммутабельности
• Нет null-safety
46. Почему не Golang?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 46 / 53
• Очень простой: 25 ключевых слов
• Нет метапрограммирования
• Нет иммутабельности
• Нет null-safety
• Из Golang легко сделать Python
47. Почему не Golang?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 47 / 53
• Очень простой: 25 ключевых слов
• Нет метапрограммирования
• Нет иммутабельности
• Нет null-safety
• Из Golang легко сделать Python
• С вендорингом какая-то боль
48. Что реально успел?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 48 / 53
• Clojure: dynamic, strong
• Elixir: dynamic, strong
• Nim: static, strong, null-unsafe
• Rust: static, strong, null-safe
49. Как ощущения?
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 49 / 53
Use libraries, not frameworks!
• Clojure: dynamic, strong
• Elixir: dynamic, strong
• Nim: static, strong, null-unsafe
• Rust: static, strong, null-safe
50. Haskell
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 50 / 53
Как открыть ВАЗ 2101 без ключа?
(Гораздо легче, чем пройти курс по Haskell*)
51. Выводы
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 51 / 53
• Я не знаю, что будет дальше
• Я не знаю, какой язык лучший
• Поэтому писать надо на всем
• Но, если можете, не пишите на COBOL
• BTW, death can be by TEX too!
53. That’s all, folks!
Александр Чистяков, Git in Sky Современные тенденции в разработке ПО 53 / 53
• alex@gitinsky.com
• https://telegram.me/lhommequipleure