Как стать автором
Обновить
96.62
Холдинг Т1
Многопрофильный ИТ-холдинг
Сначала показывать

Звоните Кузе: как мы записали FAQ для инженеров

Время на прочтение 7 мин
Количество просмотров 2.1K
image

Каждый месяц мы получаем 20–50 тысяч звонков с вопросами по обслуживанию банкоматов. Чаще всего звонят инженеры: узнать статус заявки, получить доступ, проверить версии ПО и т.п. Или инкассаторы — чтобы понять, есть ли на препарируемом ими банкомате неисправности. Вопросы в 90% случаев одни и те же.

Мы взяли движки для голосовой автоматизации и речевых технологий, объединили их и получили робота, который помогает человекам, подключили и поставили его на линию.

Функционал был тот же, что и у оператора, но инженеры принципиально не хотели общаться с роботом. Даже если это был типовой вопрос «всё ли хорошо с банкоматом?». Потом мы поменяли голос на приятный женский, протестировали в АБ с мужским — и количество переключений на оператора с робота-женщины упало: 24% обработок с Денисом и 65% с Джулией.
Читать дальше →
Всего голосов 22: ↑20 и ↓2 +18
Комментарии 12

Релизная политика против хаоса

Время на прочтение 9 мин
Количество просмотров 1.8K
image

Костя так переживал за результат релиза, что решил контролировать процесс его запуска прямиком с собственной свадьбы. Это было эпично, и привело к мысли, что в жизни пора что-то менять. Причём как можно скорее. Из всех возможных вариантов он выбрал самый интересный и решил поменять нашу релизную политику.

Нельзя сказать, что без этого всё работало плохо. Работало хорошо. Но достаточно долго. Новые фичи выходили не чаще раза в месяц, но в какой-то момент мы поняли, что нужно укладываться в две недели максимум. У нас появились такие важные показатели, как частота поставок и Time to Market.

А потом начала работать омниканальная платформа, на которой двенадцать команд одновременно разрабатывали одно приложение, каждая — свою часть. Тогда появился запрос на стандартизацию процесса.

Меня зовут Михаил Щеголев, мы вместе с Константином Дерешевым занимаемся релизной политикой в одном из крупных российских банков. Мы любим свою работу, а дедлайны не любим.

Особенно, если дело касается еженедельных релизов.
Читать дальше →
Всего голосов 23: ↑21 и ↓2 +19
Комментарии 5

Горизонтальные связи и ролевая модель большой команды

Уровень сложности Простой
Время на прочтение 12 мин
Количество просмотров 5.2K

Когда коллега уходит в отпуск или увольняется — работа часто буксует или останавливается даже в большой команде. Происходит это, так как внезапно выясняется, что ушедший был «узким местом» или «критичным звеном».

Мне удалось снизить влияние этих «узких мест» и «критичных звеньев» за счёт налаживания горизонтальных связей, построения ролевой модели большой команды и ещё нескольких приёмов.

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.

Читать далее
Всего голосов 16: ↑14 и ↓2 +12
Комментарии 9

Безопасность — это процесс, а не результат

Время на прочтение 8 мин
Количество просмотров 4K
image

Типичный ИБ-инцидент, ломающий корпоративную защиту, зачастую выглядит очень по-бытовому.

Конструктор решил взять работу на дом и скидывает на флешку всю необходимую ему для этого документацию. Дома он вставляет ее в компьютер, на который ранее скачал кучу торрентов, не подозревая, что примерно 99 % из них содержит в себе backdoor. И вот уже компания, использующая самые современные (как она думает) способы защиты, оказывается под ударом.

Есть ли реальный способ защиты от вольного или невольного инсайдера? Самым актуальным выглядит метод построения эшелонированной защиты. С ее помощью можно поднять планку гарантированной защиты очень высоко — почти до 99 %. Надо отдавать себе отчет, что 100-процентная защита недостижима в принципе: злоумышленники все время придумывают новые способы атак, и мы как будто играем с ними в шахматы, обмениваясь ходами.
Читать дальше →
Всего голосов 29: ↑23 и ↓6 +17
Комментарии 17

Учить или не учить: почему внедрение даже простого ПО не работает без погружения сотрудников

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 1.3K

Любое изменение привычного технологического стека в компании запускает трансформационный процесс, выходящий за рамки миграции данных и переустановки программ. Внедрение нового ПО можно рассматривать как отдельный большой проект, который начинается с определения целей и задач и заканчивается, когда сотрудники уже полноценно эксплуатируют продукт в рабочих процессах. 

А внутри этого проекта есть еще сбор требований к продукту, его разработка или покупка, инсталляция, настройка, обучение персонала, техническая поддержка и так далее. И пропуск любого из этапов может обернуться провалом всего внедрения. 

Например, часто в компаниях недооценивают сложность трансформационных процессов: «пересадить» людей на новый программный продукт вовсе не так просто, даже если его функции аналогичны привычному ПО. 

Читать далее
Всего голосов 2: ↑1 и ↓1 0
Комментарии 1

Опять починяем банкоматы

Время на прочтение 9 мин
Количество просмотров 6.5K
image
Источник

Банкоматы периодически ломаются. Иногда — сами, просто из-за износа механических частей, чаще — с помощью клиентов банка. В них могут застрять мятые деньги, скрепки, скотч. Может в который раз упасть винда, на которой они работают. В общем, они ломаются. Но вовремя поднятая вещь не считается упавшей, поэтому мы их быстро-быстро чиним.

Точнее, сначала робот чинит банкомат. На типовые срабатывания датчиков заводится инцидент, и робот начинает программу восстановления. Обычно это перезагрузка или сброс ошибок на конкретном модуле. Если после перезагрузки состояние сохраняется либо если поломка повторяется чаще статистической вероятности, то появляется алерт для инженера или оператора.

Если нужен физический ремонт, то робот после диагностики пишет отчёт и говорит, какие запчасти надо брать.
Читать дальше →
Всего голосов 48: ↑48 и ↓0 +48
Комментарии 11

Работа с хранилищами в Kubernetes: руководство для инженеров

Время на прочтение 21 мин
Количество просмотров 11K
image

Как DevOps-инженер я часто сталкиваюсь с необходимостью глубокого понимания тонких аспектов Kubernetes. Одним из таких ключевых элементов является управление хранилищем данных. Хотя этот элемент иногда остаётся в тени других задач, его важность для успешного развёртывания и поддержки приложений велика.

Накопленный мною опыт в этой области стал основой для этой статьи.

Я сфокусируюсь на трёх ключевых элементах управления хранилищем в Kubernetes:

  • PersistentVolumes (PV).
  • PersistentVolumeClaims (PVC).
  • Storage Classes.

Эти компоненты играют важную роль не только в выборе подходящих типов хранилищ, но и в их эффективном управлении, особенно в сценариях высокой нагрузки.

Так, при развёртывании масштабируемого веб-приложения, которое обрабатывает большие объёмы пользовательских данных и транзакций, хорошо настроенное управление хранилищем заметно повышает производительность и доступность данных. И тогда при увеличении нагрузки на приложение доступ к данным остаётся быстрым и надёжным, задержки уменьшаются, общее взаимодействие пользователя с приложением улучшается.

Например, у нас была задача обеспечить надёжное и масштабируемое хранение данных в веб-приложении для управления клиентскими заказами. Мы настроили в Kubernetes Storage Class на основе SSD для базы данных (что не является хорошей практикой): это помогло обеспечить быстрый доступ и обработку транзакций. А для логов и нечасто применяемых данных использовали отдельный Storage Class с HDD, и это позволило снизить затраты.

А главное, Storage в Kubernetes — это такая штука, которую ты сделал и забыл, дальше оно там само работает.

Рассказываю детально.
Читать дальше →
Всего голосов 49: ↑49 и ↓0 +49
Комментарии 4

Починяем банкоматы: чиним железо и софт

Время на прочтение 9 мин
Количество просмотров 7.2K
image

Ошибки софта — частый случай, почему банкомат может встать. Софт постоянно дорабатывается и развивается. Например, много всего мы узнали после обновления для работы с NFC, когда вместо карт стали использоваться телефоны. Очень интересно было при биометрических апдейтах, когда деньги снимали не с карты, а с лица. Например, там накатывали хотфикс по измерению расстояния (клиент выбрал снятие денег, наклонился завязать шнурок, деньги сняли со счёта следующего в очереди).

Вторая причина — у всякого железа есть наработка на отказ. Сейчас мы одними из первых на рынке начали заниматься превентивным обслуживанием, стараемся предугадать, когда что-то сломается и заранее пролечить, чтобы не доводить до неожиданной поломки.

И третья история, которая вызывает неисправность, — это внешние обстоятельства, в том числе клиенты. Положить пачку банкнот с резинкой или пробитых скрепкой от степлера — это каждый день. Погнутые и склеенные скотчем карты тоже часто встречаются.
Читать дальше →
Всего голосов 46: ↑46 и ↓0 +46
Комментарии 21

За одного битого двух небитых дают: как мы переобучили ручных тестировщиков на Java-автотестеров

Время на прочтение 6 мин
Количество просмотров 8.7K

Тестирование продукта — одна из самых важных составляющих процесса разработки в ИТ. Во время тестирования происходит проверка соответствия между реальным и ожидаемым поведением программы. ПО проходит верификацию, то есть оценку, удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа. Также производится валидация — проверка соответствия ПО ожиданиям и потребностям пользователя, требованиям к системе.

За счёт тестирования можно снизить стоимость продукта, потому что баги будут обнаружены до того, как компания потратит много времени и ресурсов на разработку. Кроме того, тестирование косвенно влияет на лояльность потребителей к компании и продукту, так как любой обнаруженный дефект негативно сказывается на доверии пользователей.

Помимо поиска ошибок, работа тестировщиков зачастую заключается в поиске вариантов использования ПО, которые не были предусмотрены при разработке, и в оценке UX-дизайна — они пробуют использовать программу так, как будет это делать пользователь. 

В итоге один и тот же продукт проходит множество разнообразных тестов: функциональные виды тестирования рассматривают внешнее поведение системы, а нефункциональные проверяют, как система работает — например, при установке или под большими нагрузками. Отдельная группа тестов нужна, чтобы проверить, не нарушила ли новая версия программу работу тех функций, которые уже были запущены раньше. Такое тестирование называется регрессионным, оно обычно объемное и требует больших затрат времени — если проводить его вручную.

Читать далее
Всего голосов 6: ↑4 и ↓2 +2
Комментарии 2

Ставим банкоматы в лютый мороз, жару, метро и на вездеходы

Время на прочтение 7 мин
Количество просмотров 9.1K
image
Банкомат на вездеходе для вахтового посёлка в Якутии

Мы обслуживаем банкоматы по всей стране. В практике были детективы с пылью в метро, морозы за полярным кругом, скачки напряжения на железной дороге и так далее. Где-то — сухо, где-то — влажно, где-то — мошки, где-то — спор про то, может ли «буханка» вытащить банкомат из стены.

Кстати, из тонкой стены временного здания может, из толстой капитальной — нет, не проверяйте больше, пожалуйста!

При этом банкомат — это железо, резина, различные ролики, и понятно, что эти устройства иногда не выдерживают. Например, в России из-за климата почти не устанавливаются банкоматы на улице. Вместо этого ставятся межстенные («уличные») банкоматы, где сам аппарат фактически спрятан в здание, а наружу торчит только лицевая часть, с которой взаимодействует клиент. Но наиболее часто банкоматы устанавливаются внутри зданий.

Банкоматы очень зависят от температуры, поэтому в холодных регионах нужна дополнительная защита. Например, первые аппараты были без опции «русская зима», и они замерзали. Тогда наши коллеги стали устанавливать простые печки без электронного управления. В первом релизе этих печек внутри банкомата плавились пластиковые и резиновые запчасти.
Читать дальше →
Всего голосов 49: ↑47 и ↓2 +45
Комментарии 20

Это мы пишем и обслуживаем банковский процессинг, нам надо серьёзно поговорить

Время на прочтение 11 мин
Количество просмотров 20K
В марте-22 внезапно отключились Visa и MasterCard. Это посредники передачи информации между разными банками. По сути, системы обеспечивают маршрутизацию сообщений между банками и позволяют вам использовать карту любого банка с банкоматом или платёжным терминалом другого, а заодно проверяют операции на фрод и делают ещё много чего.

Потом было 2–3 дня, когда мы не спали. Мы — это разработчики компании Мультикарты (входит в Холдинг T1) — одного из самых крупных процессингов в России, да и в мире, пожалуй.

Потом система восстановилась (не сама собой, конечно), и конечные пользователи (вы) практически не почувствовали проблем с сервисом.

Всё потому, что в России с точки зрения банкинга всё очень хорошо, и было бы странно оказаться без сапог в этой ситуации.

Мы с коллегами очень хотим начать рассказывать про практические случаи вроде того самого момента переключения систем, но боимся, что сначала нужно вообще рассказать, что такое процессинг и как он внутри устроен.

Поэтому ниже — общий рассказ про принципы процессинга. Пойдёмте ковыряться под капотом.

image
Читать дальше →
Всего голосов 88: ↑81 и ↓7 +74
Комментарии 37

Как мы растим своих джунов

Время на прочтение 11 мин
Количество просмотров 15K
image

Рынок труда изменился. Ещё недавно он был ориентирован на работодателя. Сейчас, особенно в ИТ-области, это рынок соискателей. Поиск нужных специалистов становится всё более трудным, а конкуренция на этом поле — всё более жёсткой.

Внешний рекрутинг — это чаще всего долго и довольно дорого. Есть альтернатива — профессиональное развитие сотрудников внутри организации.

Меня зовут Дмитрий Красовский, я директор Т1 Цифровой академии. Расскажу, как мы в Т1 пришли к внутреннему выращиванию талантов, благодаря которому сегодня серьёзно сокращаем расходы компании на привлечение и онбординг специалистов.

Например, сэкономили 10 млн рублей при наборе полутора десятков дата-инженеров, притом что на рынке их вообще немного, а из 200 кандидатов нам подходил один. Но благодаря новому подходу к поиску мы решили задачу за месяц, сохранив при этом внушительную сумму.
Читать дальше →
Всего голосов 43: ↑38 и ↓5 +33
Комментарии 14

Как проложить универсальные рельсы рабочих процессов и запустить по ним большую компанию?

Время на прочтение 6 мин
Количество просмотров 3K

Привет, Хабр! На связи Т1 Цифровая Академия из Холдинга Т1. Сегодня мы порассуждаем о едином производственном процессе в большой компании: почему он нужен и как его внедрить, если все команды уже работают по-своему. 

Проектный менеджмент в больших компаниях: почему необходим единый подход?

Управление проектами — это фрагмент сложной и постоянно меняющейся головоломки, которая во многом завязана на структуру компании. А эти структуры очень разнообразны: функциональные, дивизиональные, матричные, гибридные. Такая вариативность делает невозможным безоглядное перенимание лучших решений по управлению проектами. То, что сработало у лидера рынка, может оказаться неэффективным для вас чисто из-за другой организации отделов, департаментов и зон их ответственности. 

При этом вне зависимости от конкретной организационной структуры, ее элементы (или организационные единицы) неизбежно взаимодействуют между собой. Например, в компании, где есть несколько продуктовых «вертикалей» и поддерживающих их функциональных «горизонталей» (от юристов до HR), «горизонтали» часто становятся якорем, тормозящим бизнес-процессы, которые продуктовые команды выстраивают у себя по Agile. 

Банальный пример: продуктовая команда использует свою систему управления проектами и задачами, которая лучше всего отвечает сформировавшимся процессам и потребностям. Внутри команды все работает, как часы. Но как только возникает необходимость взаимодействовать с другими подразделениями — начинаются проблемы. Время уходит на передачу информации и задач, на созвоны и переписки, что-то неизбежно теряется в процессе. И вот уже часть сотрудников в команде и смежных подразделениях перегружена, сроки растягиваются, а гибкость и эффективность остались только на словах. 

Читать далее
Всего голосов 1: ↑0 и ↓1 -1
Комментарии 2

Kubernetes Networking: сервисы, Ingress и Network Policies

Время на прочтение 16 мин
Количество просмотров 12K
image

Когда я впервые столкнулся с задачей масштабирования сложного приложения в Kubernetes, то был полон оптимизма. Однако вскоре стало ясно, что управление сетевым трафиком и безопасностью в такой динамичной среде — это непросто. Наше приложение начало страдать от потерь пакетов данных и сетевых задержек, что сказывалось на общей производительности и пользовательском опыте. Из-за этого возникла потребность в глубоком понимании сетевых возможностей Kubernetes, таких, как сервисы, Ingress и Network Policies, чтобы эффективно управлять трафиком, обеспечивать безопасность и максимизировать производительность. Этот опыт стал для меня настоящим откровением и подтолкнул к написанию данной статьи.

Меня зовут Дмитрий, и я старший DevOps-инженер в ГК Иннотех. В моей работе я часто сталкиваюсь с задачами, которые требуют глубокого понимания сетевых аспектов в Kubernetes.

Например, для обеспечения стабильного взаимодействия между микросервисами я использую сервисы в Kubernetes, которые позволяют мне абстрагироваться от конкретных подов и обеспечивают надёжный механизм балансировки нагрузки.

Когда дело доходит до экспозиции наших приложений наружу, я применяю Ingress для управления входящим трафиком. Это не только упрощает настройку SSL/TLS, но и предоставляет гибкие возможности для маршрутизации. И, конечно же, безопасность стоит не на последнем месте. С помощью Network Policies можно тонко настроить сетевые правила, определяя, какие поды могут взаимодействовать друг с другом, что значительно повышает уровень безопасности нашей инфраструктуры.

Данная статья будет особенно полезна для DevOps-инженеров, системных администраторов и архитекторов, которые хотят глубже понять механизмы сетевого взаимодействия в Kubernetes.

Сосредоточимся на критически важных элементах, таких, как сервисы, Ingress и Network Policies. Освоение этих базовых принципов не только упростит вашу работу с Kubernetes, но и даст вам уверенность в управлении сложными системами. Надеюсь, это будет полезно!
Читать дальше →
Всего голосов 55: ↑53 и ↓2 +51
Комментарии 6

Самый маленький Docker образ Rust приложения

Уровень сложности Средний
Время на прочтение 5 мин
Количество просмотров 8.9K

Привет %username%, эта статья про то, как поместить Rust приложение в Docker и получить образ размером с бинарный файл (6 Мб). А также про причины, которые привели к переходу с NodeJS на Rust. Отдельная пара слов о проблемах вначале, переходе на Go, и том, как команда Rust устранила эти проблемы за пол года.

TL;DR Dockerfile в конце статьи и ссылка на example репозиторий

Читать далее
Всего голосов 45: ↑44 и ↓1 +43
Комментарии 16

Как мы решили вопрос нехватки кадров, обучив соискателей работе с Apache Spark

Время на прочтение 6 мин
Количество просмотров 4.3K

Привет, Хабр! На связи Т1 Цифровая Академия из Холдинга Т1. Сегодня расскажем о
том, как мы помогали клиенту справиться с нехваткой data-инженеров и увеличить темпы найма, дообучая кандидатов навыкам работы с Apache Spark на реальных задачах компании.

Читать далее
Всего голосов 7: ↑5 и ↓2 +3
Комментарии 4

Графовый анализ: как вычислить первый фрод или увольняющегося сотрудника (первые шаги)

Уровень сложности Простой
Время на прочтение 13 мин
Количество просмотров 23K
image

Любая организация в значительной степени зависит от действий людей: клиентов, партнёров, своих сотрудников. И все люди — разные: одни — добросовестные и честные, другие — хитрые и не прочь обмануть, третьи — слабовольные и зависят от чужого влияния.

И вопрос оценки надёжности людей, взаимодействующих с компанией, всегда актуален. Чем точнее будет эта оценка, тем в более выгодном положении будет компания и тем меньшими средствами она рискует. Чтобы управлять всеми этими факторами и, более того, прогнозировать на основе получаемой извне и изнутри информации свои действия, сегодня используются системы графовой аналитики.

Сейчас расскажу, что это, как работает и что с этим можно делать.
Читать дальше →
Всего голосов 56: ↑35 и ↓21 +14
Комментарии 17

Не Oracle единым: как мы обучили сотрудников PostgreSQL и сократили миграции БД на полгода

Время на прочтение 7 мин
Количество просмотров 8.9K

Привет, Хабр! На связи Т1 Цифровая Академия из Холдинга Т1. Сегодня хотим рассказать, как мы добились того, что 233 специалиста перешли с Oracle на PostgreSQL всего за 10 месяцев.

Почему часто лучше обучить, чем нанять

В начале 2022 года внешние условия резко поменяли картину мира и ИТ-отрасль. Во-первых, иностранные поставщики решений — Microsoft, IBM, Cisco, Adobe и не  только — ушли с российского рынка, и ИТ-специалисты остались один на один с отечественными разработками и альтернативными ИТ-решениями, которые приходилось изучать по ходу работы. Во-вторых, в среднем отрасли не хватает около 1 млн ИТ-специалистов, особенно уровня middle и senior. На поиск кандидатов с опытом от 6 лет может уходить до полугода. Такое положение дел заставляет бизнес искать альтернативы найму новых сотрудников с нужными знаниями.

Как представители одного из лидеров ИТ-отрасли мы понимаем, что сейчас постоянный апгрейд знаний в ИТ — основа основ. Компаниям выгодней взрастить текущие кадры, раскрыть их сильные стороны и улучшить навыки, чем потратить от 3-х месяцев на поиск идеального кандидата в условиях нехватки кадров.

Почему переход с одной СУБД на другую — это вызов

Одна российская компания обратилась к нам за помощью — ей требовалось импортозаместить Oracle на PostgreSQL за 1 год. По оценкам команд это заняло бы минимум 1,5 года из-за отсутствия специалистов по PostgreSQL, затяжной миграции и низкой мотивации специалистов. 

Такой длительный переход мог существенно затормозить бизнес-процессы: если в процессе перехода лицензия закончится, то купить новую уже не получится; при отсутствии технической поддержки со стороны Oracle нельзя будет устранить технические ошибки, из-за которых можно остаться без функционирующих БД как у всей компании, так и у заказчиков. Сбои в работе ПО, которые работают на основе БД, могли бы повлечь и более серьезные проблемы. А потеря данных была бы вовсе критической.

Читать далее
Всего голосов 7: ↑5 и ↓2 +3
Комментарии 7

Process Mining. «Рентгеновская диагностика» бизнеса

Уровень сложности Простой
Время на прочтение 12 мин
Количество просмотров 6.1K
image

Представьте себе, что компания одновременно закупает буровую вышку и ручки с карандашами в офис. На все заявки вне зависимости от стоимости есть KPI на сроки рассмотрения, допустим, 15 дней. Процесс идёт по одному и тому же пути — 15 шагов, а в финале — согласование у главного бухгалтера. KPI соблюдаются, в отчётах всё ОК.

По идее, для ручек это должно происходить легче и быстрее, чем для буровой установки. В данном же случае получается, что для компании это одно и то же и процессы одинаковые. Но вот их цена в пересчёте на эффект разная. И нужно понять, как оптимизировать процессы, чтобы убрать лишние расходы.

То, что главный бухгалтер согласовывает закупку ручек, — дороговато для процесса, и его можно разгрузить. А в сложных закупках к тем пятнадцати уникальным шагам могут добавиться зацикливания, пересогласования, то есть получится намного больше повторных действий, чем при согласовании ручек. Возможно, каждый сотрудник участвует по два-три раза в этой крупной сделке. Это увеличивает нагрузку на процесс. А финальный KPI (15 дней) — тот же самый, только цена того, что происходит посередине, намного больше. Это как раз то, что с помощью обычной отчётности не выявляется.

Получается, что для разного типа закупок стоимость процессов в пересчёте на эффект имеет очень сильное расхождение. При этом каждый процесс может где-то сбоить и зацикливаться.

Важно выявить, в каком месте это происходит и какую на этом можно получить экономию.

Process Mining помогает очень быстро увидеть взаимосвязь между событиями и показать, между какими этапами происходит зависание. В большинстве случаев в результате получается весьма ощутимый финансовый эффект.
Читать дальше →
Всего голосов 28: ↑27 и ↓1 +26
Комментарии 7

Работа с JSON в Rust. Методичка

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 5.8K

Привет Хабр! Меня зовут Алексей, я разработчик Группы "Иннотех" Холдинга Т1.

Цель статьи - познакомить читателя с библиотеками для работы с JSON в Rust. Если вы никогда не парсили JSON на языке Rust и ищите с чего начать, то эта статья для вас!

В статье будут разобраны примеры работы со строками и файлами, познакомимся с библиотеками serde и serde_json

Читать далее
Всего голосов 14: ↑8 и ↓6 +2
Комментарии 4

Информация

Сайт
t1.ru
Дата регистрации
Дата основания
Численность
свыше 10 000 человек
Местоположение
Россия
Представитель
Холдинг Т1