Русский
Русский
English
Статистика
Реклама

Lamoda

Технорадар Lamoda 2020 что изменилось за два года

26.10.2020 12:15:22 | Автор: admin
Технологический радар диаграмма, на которой можно увидеть IT технологии и инструменты, которые мы используем в Lamoda, разделенные по областям применения и статусам. В 2018 году мы выкладывали здесь на Хабре подробную статью с расшифровкой актуального на тот момент техрадара. Что изменилось за два года, и зачем мы продолжаем регулярно обновлять радар читайте в этой статье.

image

На самом деле, технологический радар не просто картинка, которую мы можем показать на конференции. Хотя мы используем его и так тоже он отлично подходит, чтобы составить быстрое впечатление об IT-составляющей нашей компании. В 2018 году мы были единственной компанией, которая использовала для представления такой инструмент визуализации а сейчас на каждой конференции мы с радостью замечаем по 2-3 новых радара у различных компаний. Что сказать это действительно очень наглядно и удобно!

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

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

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

Я буду подробнее говорить про это дальше, но хочу подчеркнуть сразу: политика Архитектурного комитета направлена не на то, чтобы запрещать экспериментировать с новыми технологиями, а на то, чтобы эти эксперименты были более осознанными и управляемыми. Наши специалисты не оказываются зажаты в узкие рамки конкретных языков и инструментов на всё время работы в компании. Наоборот, благодаря понятному циклу внедрения новых (или хорошо забытых старых) технологий, если специалисту становится скучно с теми инструментами, с которыми он работает, мы практически всегда можем предложить ему принять участие в экспериментальном проекте. При этом ему не придётся полностью менять направление, и он сможет использовать накопленную экспертизу по той системе, над которой работал.

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

Пройдем последовательно по четырем секторам радара, соответствующим основным IT-направлениям: Языки, Управление данными, Платформы и Инфраструктура, Фреймворки и Инструменты.

Но сначала напомню, что означают четыре слоя (статуса принятия технологии) на нашем радаре:

  • ADOPT технологии и инструменты, которые внедрены и активно используются;
  • TRIAL технологии и инструменты, которые уже прошли этап тестирования и готовятся к тому, чтобы работать с продакшн (или даже уже работают там);
  • ASSESS пробные инструменты, которые в данный момент оцениваются и пока не влияют на продакшн. С их участием реализуются только тестовые проекты;
  • HOLD в этой категории у нас есть экспертиза, но упомянутые инструменты используются только при поддержке существующих систем новые проекты на них не запускаются.

Языки



image

Как видите, по сравнению с 2018 годом точек в этом секторе стало меньше. Прямо сейчас у нас нет никаких языков в статусе Assess или Trial. Почему так получилось? Для каждой задачи у нас уже есть язык, который нас устраивает. Конечно, мы следим за развитием области и знаем интересные и перспективные языки, которые не используются сейчас в Lamoda, например Rust, но по своим возможностям они являются по сути дублирующими для тех, на которых написаны наши системы. Собственно, одна из целей ведения радара как раз в том, чтобы внедрение новых технологий происходило осознанно и с четким пониманием, какие плюсы нам это принесёт а не просто потому, что язык модный и о нем все говорят.

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

Именно так у нас произошло с Go. Когда мы начали активно развивать микросервисную архитектуру, то поняли, что Go для решения многих задач подходит лучше, чем PHP, на котором мы привыкли писать. Да, потребовалось приложить некоторые усилия, чтобы всей командой перейти на него (подробнее мы писали об этом тут). Но в результате очень выросла скорость работы приложений, да и по другим параметрам язык оказался удобен. За два года его стало у нас гораздо больше, в частности он практически полностью вытеснил Python из веб-разработки (но, конечно, Python остался в Data Science и других местах, где необходимо работать с большими массивами данных в таких задачах он однозначно лидер).

На радаре 2018 года видно, что мы пробуем Kotlin, но в 2020 мы уверенно присваиваем ему статус Adopt. Больше двух лет назад мы решили перевести часть Android-разработки на Kotlin язык казался очень перспективным, а наше мобильное приложение только развивалось и мы могли позволить себе эксперимент. Сейчас мы однозначно рады, что приняли такое решение. Не только все наши приложения под Android написаны на этом языке, но также часть бэкенда пока что это эксперимент, но мы возлагаем на него большие надежды. Помимо других очевидных достоинств, Kotlin очень универсальный язык а это значит, что на нем можно писать разные части систем, и передача экспертизы между командами сильно упрощается. И находить новых специалистов на рынке тоже становится проще.

Также по сравнению с 2018 годом из Trial в Adopt переместился TypeScript.
Он сильно расширяет возможности JavaScript, а весь наш огромный сервис доставки написан на нём, работает отлично, и мы пока не планируем это менять.

Управление данными


image

Практически все базы данных у нас по-прежнему реализованы на PostgreSQL (также мы используем MongoDB, а вот MySQL окончательно перевели в статус Hold).

Но за прошедшие два года у нас появились и новые технологии. В настоящий момент мы пилотируем использование СУБД Greenplum для задач развития нашей платформы данных. В нашем арсенале есть Oracle и Vertica прекрасные базы, но мы ищем способы удешевить стоимость владения инфраструктурой, поэтому рассматриваем Opensource решения. Возможно, это будет не замена, а дополнение время покажет.

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

Также мы внедрили Oracle APEX в качестве создания Web интерфейсов для ведения ручных справочников в хранилище данных. Ранее для этого использовались XLS-файлы, загружаемые с сетевого диска. Oracle APEX позволил нам сделать удобный интерфейс для бизнес-пользователей, теперь они могут самостоятельно обновлять данные в удобном Web приложении.

На радаре изменений в этом месте нет, но стоит отметить еще более глубокое проникновение Apache Airflow в процессы создания платформы данных. Сейчас это основной оркестратор задач обработки данных, он пришел у нас на замену Luigi.

Интересно произошло с RabbitMQ в свое время мы внедрили его, но он не всем нас устраивал, и мы даже думали совсем от него отказаться. Но потом пришли новые специалисты в команду администрирования, и оказалось, что RabbitMQ хорош, мы просто не умели его готовить. После того, как мы перешли с FreeBSD на Linux, RabbitMQ уверенно находится в статусе Adopt.

Платформы и инфраструктура


image

Вот здесь большие изменения произошли. Когда мы первоначально выбирали инструменты для деплоя, то остановились на связке Nomad + Consul. У нас был большой кредит доверия к компании Hashicorp, которая их выпускает, и в целом решение нас устраивало пока не произошло несколько критических падений при апгрейдах оборудования. Устранение неполадок каждый раз требовало много времени и ресурсов, а компания понесла определенные убытки. Тогда мы перешли на ставший более популярным Kubernetes.
Возможно, новые версии Nomad работают более стабильно, но у нас после той истории, можно сказать, остался шрам так что нет желания проверять. Тем более, что Kubernetes в связке с Docker нас полностью устраивают.

Фреймворки и инструменты


image

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

image
Например, мы пробовали разные фреймфорки для JavaScript, но старались экспериментировать на некритичных для бизнеса задачах. А главное, мы помнили, что это эксперимент, и в итоге мы хотим выбрать минимальный набор подходящих нам инструментов. Такая политика привела к тому, что React, например, так и не стал использоваться на проде. Angular и другие фреймворки ушли в статус Hold, и в основном на фронтенде мы используем vue.js, который показал себя в этом соревновании лучше остальных.

Естественно, какие-то фреймворки уходят вместе с языками, для которых их использовали. Так например произошло у нас с Django, когда Go почти полностью вытеснил Python из веб-разработки.

Это нам подходит!


В заключении статьи 2018 года мы сказали в двух словах мы пишем на GO, PHP, Java, JavaScript, держим базы на PostgreSQL, а деплоим на Docker и Kubernetes.
Такое обобщение верно и сейчас единственное, в список основных языков однозначно ворвался Kotlin.

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

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

Конечно, на рынке будут появляться новые инструменты, которые подходят нам больше тех, что мы используем сейчас.
Мы рассчитываем, что в нашей системе естественного отбора технологий эти инструменты пройдут свой путь от Assess до Adopt и при необходимости заменят текущие.
Подробнее..

Как работать в команде, которая пишет на 5 языках

23.04.2021 12:19:27 | Автор: admin

Привет, Хабр! Меня зовут Евгений Сальников, я тимлид одной из команд доставки в компании Lamoda. В нашей команде используются сразу пять языков программирования: PHP, Go, Vue, Typescript, Java и Kotlin. Когда я впервые услышал об этом на собеседовании, подумал, что так работать невозможно все слишком разное. Но спустя год мое мнение кардинально изменилось, и я нашел много преимуществ в таком подходе.


В этой статье я расскажу:


  • о нашем направлении и системах, обслуживающих доставку;
  • как мы живем с таким разнообразием технологий;
  • как планируем работу над разноплановыми задачами;
  • как растим экспертизу в fullstack-команде и расширяем направление.


Почему fullstack?


Мы часто слышим про fullstack это устоявшееся понятие, даже избитое. Оно подразумевает, что один человек может пилить и бекенд, и фронтенд все в одном флаконе. Сейчас в нашем направлении уже четыре команды из 27 человек, пять языков и четыре системы.


  1. DataMatrix это система для маркировки товаров. В нашей стране существует закон 487-ФЗ, по которому мы обязаны помечать ряд товаров QR-кодом. Маркировка содержит информацию о том, кто произвел этот товар, кто ввез в страну, когда он поступил в продажу. Это помогает понять, насколько легальная вещь лежит перед нами. Подробнее о DataMatrix рассказывали в отдельной статье.
  2. Система Express стоит в каждом пункте выдачи заказов и во всех транзитных складах. Она целиком написана с нуля внутри Lamoda, поэтому там учтены все наши процессы и потребности. На текущий момент вся система доставки построена на Express.
  3. Система XDC взаимодействует с внешними службами доставки с Почтой России, DPD и остальными.
  4. Также в зоне ответственности нашего направления мобильное приложение для торговых представителей, у которых есть планшет или телефон с ПО нашей разработки.

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


Мой любимый пример Apache Camel. Это интеграционный фреймворк на Java, который, грубо говоря, перекладывает данные из одного места в другое. У нас в компании эта технология обеспечивает взаимодействие с внешними курьерскими службами: мы получаем данные о заказе из API, преобразовываем их и отправляем в курьерскую службу. Написать эту задачу на РНР возможно, но будет неоправданно, потому что Apache Camel и так уже создан для этих целей. Такой подход позволяет легче адаптировать новые службы и новые API, тратить меньше времени на преобразование запроса из Json в XML. В Lamoda это адаптированная технология: если одна команда научилась ее готовить, мы делимся знаниями с коллегами. Сейчас Apache Camel используется уже в четырех командах.


Распределение ролей, покер-планирование и рост экспертизы


Раньше мне казалось, что существует жесткое разделение по системам. Например, пять человек занимаются одной системой, еще пять занимаются другой и просто взаимодействуют друг с другом. У нас такого нет. Каждый инженер команды может дорабатывать любую систему.



Например, у нас есть задача сделать удобную форму возврата. Для контроля технической стороны этого проекта мы назначаем техлида, которым может стать любой инженер из команды. Уже заранее он понимает, что для поставленной цели придется затронуть две системы: Express и XDC.


На схеме видно, что у Express и XDC также есть техлиды. У Express их даже два это очень большая система. Таким образом, техлид проекта сообщает техлидам систем о необходимых доработках, составляет и декомпозирует задачи, следит за тем, чтобы работа шла консистентно.


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


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



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


Приведу несколько примеров нашего подхода к работе:


  • Раньше я часто сталкивался с тем, что есть отдельная команда для бэкенда и API мобильного приложения, а другая команда дорабатывает само приложение. Это требует формализации всех процессов и задач. У нас же один и тот же человек в одном спринте дорабатывает бэкенд и API мобильного приложения, да и само мобильное приложение. И это не разные задачи, а один проект по общим изменениям. На мой взгляд, это позволяет двигаться быстрее.
  • Следующий пример о том, как мы близки к инфраструктуре. В нашем направлении используется K8s и Atlassian. Все скрипты для разворачивания новых серверов или деплоя приложения также создаются внутри команды. Любой из наших инженеров может поправить скрипт деплоя или что-то написать на Ansible, чтобы развернуть новый сервер. Благодаря этому мы быстрее делаем доработки.
  • В нашей команде есть сервисы, написанные на Go, но исключительно утилиты. Часто бывает так, что нам нужно запросить миллион Data matrix у внешнего API. В этом случае писать большие истории на РНР невыгодно, потому что для этих целей создан Go. Это бы усложнило ситуацию, если инженер совсем не знаком со сторонними API и с нашими процессами. Но наши ребята могут написать нужную утилиту на подходящем языке. Go адаптирован к нашей компании. У нас есть экспертиза в этом, мы можем пойти к соседним командам и уточнить у них все вопросы.

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


Мои итоги спустя год: как расширять fullstack-команду


Fullstack-программист стоит дороже, чем остальные. В HR-отделе на вас посмотрят с недоумением, когда вы попросите найти специалиста, который умеет Go, Java, Kotlin и отлично знает РНР.


Есть три способа увеличить команду:


1. Брать со стороны. Чтобы попасть в нашу команду, не нужно знать все пять языков. На старте большинство из нас были с ними не знакомы. Достаточно знать РНР и SQL и не бояться работы с остальными технологиями и языками. Мы на каждом интервью сразу же говорим о том, что у нас используется несколько языков.


Также у нас выстроен процесс онбординга он длится 3 месяца. Каждый новичок получает план из набора технических задач, которые в совокупности охватывают все наши системы и технологии. Например, сначала РНР-разработчик начинает знакомиться с системой Express, а потом может выбрать другие задачи, исходя из своих интересов: кому-то больше интересен Kotlin, кто-то уже имеет экспертизу на Go. Также происходит постепенное погружение и в процессы команды: дежурства, знакомство с системой мониторинга, выполнение саппорт-задач.


2. Растить внутри. Процесс, запущенный на онбординге, не заканчивается ровно через 3 месяца. Человек по-прежнему продолжает погружаться в наши процессы, а его технологическая экспертиза растет. Со временем он может занять роль техлида. Для этого инженер знакомится сначала с системой, потом с бизнес-требованиями к ней, а со временем понимает, что бизнес-требования слишком велики для одной задачи. В таком случае он может стать техлидом этого проекта или системы. Погружение в такую работу происходит только через практику.


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


В таком подходе важно понимать, что разработчик это инженер. Для меня инженер это человек, который продолжает учиться, искать что-то новое и понимает, какие технологии лучше подходят для решения конкретной задачи. Ему важно постоянно развиваться, не зацикливаясь на чем-то одном. Я верю, что смена проекта помогает разнообразить жизнь инженера. Очень здорово, когда в команде есть несколько проектов, между которыми можно переключиться и попробовать разное. Это не даст заскучать.


3. Смена технологий. Это тоже отличный путь развития. Сначала я познакомился с РНР, и казалось, что на нем можно сделать абсолютно все. Но сейчас будет странно писать на РНР постоянно живущие воркеры. Для этого можно использовать другие языки. Или, например, когда я познакомился с Go, это казалось крутым, но чего-то не хватало, зная количество готовых библиотек для Java. Новые инструменты помогают лучше понять те, которыми уже владеешь.


За неполный год в мою команду добавилось еще 10 инженеров. Сейчас это уже целое направление. Но не все готовы работать в таком подходе: кому-то не зашёл фронтенд, кому-то не заходит разнообразие технологий. Это не значит, что ушедшие люди плохие инженеры. Мы работаем в огромной компании, поэтому возможен переход в другие команды внутри Lamoda. Бывают и обратные случаи, когда люди из других команд переходят в наше направление, и это тоже круто.


Новые языки и комплектность команды


Мы уже сталкивались с появлением новых языков: кто-то сразу же на них кидается, кто-то ждет, когда появятся стабильные версии. Мы не отрицаем тот факт, что какие-то задачи можно реализовать легче или быстрее на других технологиях. Да, не нужно зацикливаться на чем-то одном, но лучше здраво подходить к каждому выбору. Если появятся новые языки или новые технологии, которые позволят нам двигаться быстрее, конечно, мы их рассмотрим.


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


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

Подробнее..

Lamoda x Joker 2020

18.11.2020 16:23:31 | Автор: admin
Привет, Хабр! Меня зовут Влад Кошкин, я java-разработчик в Lamoda. С 25 по 28 ноября наша команда впервые примет участие в онлайн-конференции Joker 2020.

У Lamoda огромный и сложный склад: 40 000 м, миллионы товаров на полках, тысячи людей и все это мы автоматизируем на Java через WMS (Warehouse Management System).

image

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

Расписание активностей


Мы записали мини-доклады, чтобы вы могли посмотреть их на стенде в любое время, а не пытались попасть в определенный слот :)

imageКак мы подружили Kotlin и склад, а также другие технические потребности WMS Влад Кошкин, java-разработчик.

Поговорим о том, почему мы обратили внимание на Kotlin и как он прижился в бекенде. Узнаем, как сейчас решаются проблемы с балансировкой и обновлением клиентских устройств на складе. Я расскажу про планы на систему WMS на ближайший год.


imageКак мы строим модульную архитектуру без микросервисов Женя Рябышев, java-разработчик.

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

imageБез лишних встреч: как мы позволяем разработчикам разрабатывать Костя Карусев, тимлид команды Acinonyx.

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

Мы будем на стенде три дня, приходите пообщаться с нами в перерывах конференции.

Байки со склада: Автоматизация

26 ноября 12:00 12:30

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

Байки со склада: Черная Пятница

27 ноября 18:00 18:30

Для e-commerce сегодня главный день в году Black Friday. В этот вечер будем травить байки о том, как мы обычно справляемся с пиковыми нагрузками.

Байки со склада: Внутренняя продуктовая разработка

28 ноября 12:00 12:30

Обсудим разницу между inhouse разработкой и софтом на продажу.

Квест: Расследуй самые сложные случаи на складе.


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

image

До встречи на Joker 2020!
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru