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

Блог компании it-people

Почему так сложно писать код? Григорий Петров о физиологии мозга и управлении личной и командной эффективностью

13.04.2021 20:10:28 | Автор: admin

Секция Team на конференции DUMP про людей и для людей. В этом году не будет никаких скрамов и канбанов, зато будет много инструментов для повышения эффективности работы в командах. Мы поговорили с Григорием Петровым, DevRel из Evrone. Гриша - разработчик с 20-летним стажем, нейрофизиолог-любитель и технический евангелист. На DUMP он выступит с докладом Физиология мозга: рычаги управления личной эффективностью.

  • Гриша, привет! На 10м юбилейном Дампе ты выступишь с темой про физиологию мозга и рычаги управления личной эффективностью. Мы ждали твой доклад целый год! Мы знаем, как ты много и с интересом исследуешь тему нейрофизиологии. Расскажи подробнее, о чем будет твой доклад?

    • За последние годы нейрофизиология накопила результаты миллионов исследований, каждое из которых показывает маленький кусочек мозаики. Целиком мозаика складываться отказывается: есть десятки гипотез "как может работать сознание" и ноль ответов на вопрос "почему так сложно писать код". Для доклада я выбрал несколько гипотез, которые нравятся лично мне. Через их призму я осмотрю наши основные сложности: код, прокрастинация, целеполагание и другие штуки, с которыми мы сталкиваемся каждый день.

  • Методик для достижения личной эффективности описано много: состояние потока, однозадачность, тайм-менеджмент с учетом биоритмов и другие. Этого недостаточно?

    • Есть множество книг вроде "500 способов стать хорошим программистом, прекратить прекращать и начать начинать". В таких книгах обычно собрано все: работающие способы, неработающие способы, способы, которые не делают ничего и по цистерне воды на каждое печатное издание. Нейрофизиология, в противовес труизмам, пытается предложить гипотезы "как это работает". А хорошая гипотеза вскрывает закономерности, знание которых позволяет не учить сотни частностей. Зачем изучать сотни способов "тайм-менеджмента с учетом биоритмов", если знание одной закономерности позволит вывести любое количество таких способов?

  • А какие методики по повышению личной эффективности ты пробовал на себе? Что зашло, а что не получилось?

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

  • С чего началось твоё увлечение нейрофизиологией?

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

  • Где ты берёшь информацию? Какими источниками пользуешься?

    • Учебники. 5-я редакция "Principles of neural science" у меня настольная книга: 1400 страниц, твердый переплет, 5 килограмм живого веса. Скоро ее заменит 6-е издание, а помогают учебники поменьше. PubMed, опять же. Ну и секретные telegram чаты нейрофизиологов, конечно. Куда же без них.

  • Как ты используешь свои знания по нейрофизиологии в жизни и работе сегодня? Расскажи про свои ежедневные ритуалы.

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

  • Что делать, если ты уже гуру планирования, но вот твоя команда...ещё прокрастинирует?

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

  • Главное, что запомнит аудитория после твоего рассказа? Чем он будет полезен?

    • Собственно, весь мой доклад сводится к одной фразу: "мы делаем не то, что правильно, логично или разумно, а то, что привыкли делать". Но чтобы применить это заклинание на практике нужно будет послушать немного теории и занимательных историй про зрительную кору, когнитом и attention schema.

    БЛИЦ:

  • Ты выступаешь на конференциях, участвуешь в митапах, берешь интервью у крутых людей... а код писать успеваешь?

    • Не отвлекайте, я занят :)

  • Есть ли у тебя увлечения, не связанные напрямую с it, кроме нейрофизиологии?

    • В количестве: компьютерные игры, аниме, журнализм, японский язык. Это из тех, о которых можно рассказать в приличном обществе.

  • Как ты переключаешься, как отдыхаешь?

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

  • Твои слушатели получают гору полезности из твоих выступлений. А что работа с аудиторией даёт тебе?

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

  • Что тебя мотивирует?

    • Моя мечта - научиться обучать уверенных мидлов-разработчиков быстрее, чем за полтора года. Рынок труда, какой он есть сейчас, очень мотивирует.

  • Вернись на 10 лет назад, что себе посоветуешь/скажешь?

    • "Не води рейды в World of Warcraft, разочаруешься. Води разработчиков выступать - тебе понравится!"

  • А кем видишь себя через 10 лет?

    • Мне бы хотелось задержаться в DevRel и научиться обучать разработчиков не только выступать, но и писать код. Каждый день я пользуюсь сотнями программных продуктов - хочется, чтобы их писали крутые ребята и девчата, которые знают, что делают. А чтобы они знали, их нужно обучать.

Есть ещё вопросы? Можешь задать их Грише 14 мая на конференции DUMP-2021! Билеты на офлайн/онлайн и программа выступлений здесь.

Подробнее..

Сочетать карьеру agile-коуча и стендап-комика? Легко и приятно! Рассказывает Илья Якямсев

30.04.2021 22:19:48 | Автор: admin

В этом году в секции Team на DUMP выступит agile-коуч компании Wiley Илья Якямсев. Мы поговорили с Ильей о его докладе, злом стендапе и о том, как сценический опыт помогает вести тренинги.

Илья, привет! На DUMP ты выступишь с докладом Говорите, пожалуйста! Как построить эффективную коммуникацию в команде. А еще ты выступаешь как стендап-комик. Мы не будем тебя просить шутить в нашем интервью, а будем просто задавать вопросы тебе-менеджеру, и тебе-комику.

  • Расскажи подробнее, о чем будет твой доклад? Можно немного спойлеров:)

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

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

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

  • Ты постоянно работаешь с людьми, выстраиваешь и оттачиваешь процессы в командах... Много ресурсов отнимает у тебя самого постоянная коммуникация?

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

  • Где ты учился взаимодействию в команде (или с этим рождаются?) и как прокачивал этот полезный скилл?

Я всегда старался брать обратную связь от всех людей с кем работал и старался хоть маленько изменять на практике своё поведение. И ещё я много читаю и смотрю видео как работают другие люди.

Да, важно - мне это нравится.

  • Как на работу твоей команды повлияла пандемия? Что изменилось?

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

Частично и об этом буду говорить в своём докладе.

  • С чего начиналась твоя карьера agile-коуча? Что считаешь твоим (командным) успехом, а что - провалом?

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

Труднее всего не давать советы и не пытаться прямым действием исправить систему. К этому пытаюсь привыкнуть.

  • Как ты пришел к своему увлечению стендапом? Какой момент стал поворотным?

Мне понравился Камеди Клаб, потом я начал писать тексты в Самарский Камеди Клаб, потом начал выступать сперва с монологами Десять шуток на одну тему. После года занятий я открыл в сети стендап, меня немедленно выгнали со сцены с формулировкой никогда больше здесь не будет ни тебя, ни вот этой вот отвратительной вещи. Потом года через три мы в городе всё-таки додумались делать открытые микрофоны, и вот с 2013 года я регулярно выступаю.

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

  • Какие комики тебя вдохновляют? А проекты и команды?

Меня вдохновляют комики с идеями, где кроме шуток есть интересные точки зрения и/или не банальная литература. Даг Стенхоуп, Джордж Карлин, Саймон Амстел, Эдди Изард, Стюарт Ли.

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

  • Где ты берешь материал для шуток? Как его отрабатываешь и проверяешь? Кто герои твоих выступлений?

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

  • Что ты чувствуешь, когда стоишь на сцене, слышишь смех в зале? А когда выступаешь на конференциях? А прорывается наружу стендапер?

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

Чувствую удовольствие. Иначе бы не занимался.

  • Шутишь ли ты про работу со сцены? И наоборот - привносишь ли опыт комика в работу?

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

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

Ну и тренинги мне из-за этого опыта вести легко и приятно.

  • Есть вероятность, что тебе надоест карьера в Wiley и ты будешь собирать залы?

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

  • Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

Не метаться, идти в одну сторону, и если пошёл, то не пытаться в трудные минуты вернуться обратно. Но вряд ли это получилось бы у меня десятилетней давности, это наживное.

Да, ещё хороший совет - не бросать основную работу пока не нашёл другую основную работу.

  • А кем видишь себя еще через 10 лет?

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

Мне очень нравится удалёнка.

  • На DUMPе ты мы увидим твой полезный доклад для менеджеров разработки. А где можно посмотреть твой стендап (вживую - мы все очень соскучились по офлайну)?

У меня будет концерт в Екатеринбурге, его организуют местные ребята в лофте Место. Вечер 14 мая в 22:00 (после конференции). Приходите, если что.

А послушать Илью как спикера секции Team можно 14 мая в конгресс-центре ЭКСПО оффлайн или в нашей онлайн-трансляции. Билеты выбирай здесь!

Увидимся на DUMP!

Подробнее..

Agile-коуч Илья Якямсев об эффективной коммуникации в команде, докладе на конференции DUMP и пользе стендапа

05.05.2021 10:13:29 | Автор: admin

В этом году в секции Team на DUMP выступит agile-коуч компании Wiley Илья Якямсев. Мы поговорили с Ильей о его докладе, злом стендапе и о том, как сценический опыт помогает вести тренинги.

Илья, привет! На DUMP ты выступишь с докладом Говорите, пожалуйста! Как построить эффективную коммуникацию в команде. А еще ты выступаешь как стендап-комик. Мы не будем тебя просить шутить в нашем интервью, а будем просто задавать вопросы тебе-менеджеру, и тебе-комику.

  • Расскажи подробнее, о чем будет твой доклад? Можно немного спойлеров:)

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

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

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

  • Ты постоянно работаешь с людьми, выстраиваешь и оттачиваешь процессы в командах... Много ресурсов отнимает у тебя самого постоянная коммуникация?

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

  • Где ты учился взаимодействию в команде (или с этим рождаются?) и как прокачивал этот полезный скилл?

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

  • Как на работу твоей команды повлияла пандемия? Что изменилось?

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

Частично и об этом буду говорить в своём докладе.

  • С чего начиналась твоя карьера agile-коуча? Что считаешь твоим (командным) успехом, а что - провалом?

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

Труднее всего не давать советы и не пытаться прямым действием исправить систему. К этому пытаюсь привыкнуть.

  • Как ты пришел к своему увлечению стендапом? Какой момент стал поворотным?

Мне понравился Камеди Клаб, потом я начал писать тексты в Самарский Камеди Клаб, потом начал выступать сперва с монологами Десять шуток на одну тему. После года занятий я открыл в сети стендап, меня немедленно выгнали со сцены с формулировкой никогда больше здесь не будет ни тебя, ни вот этой вот отвратительной вещи. Потом года через три мы в городе всё-таки додумались делать открытые микрофоны, и вот с 2013 года я регулярно выступаю.

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

  • Какие комики тебя вдохновляют? А проекты и команды?

Меня вдохновляют комики с идеями, где кроме шуток есть интересные точки зрения и/или не банальная литература. Даг Стенхоуп, Джордж Карлин, Саймон Амстел, Эдди Изард, Стюарт Ли.

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

  • Где ты берешь материал для шуток? Как его отрабатываешь и проверяешь? Кто герои твоих выступлений?

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

  • Что ты чувствуешь, когда стоишь на сцене, слышишь смех в зале? А когда выступаешь на конференциях? А прорывается наружу стендапер?

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

  • Шутишь ли ты про работу со сцены? И наоборот - привносишь ли опыт комика в работу?

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

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

  • Есть вероятность, что тебе надоест карьера в Wiley и ты будешь собирать залы?

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

  • Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

Не метаться, идти в одну сторону, и если пошёл, то не пытаться в трудные минуты вернуться обратно. Но вряд ли это получилось бы у меня десятилетней давности, это наживное.

Да, ещё хороший совет - не бросать основную работу пока не нашёл другую основную работу.

  • А кем видишь себя еще через 10 лет?

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

Послушать Илью как спикера секции Team можно 14 мая в конгресс-центре ЭКСПО оффлайн или в нашей онлайн-трансляции. Подробнее о программе.

Подробнее..

Три способа стать геймдизайнером, иконы игр и тренды GameDev. Интервью конференции DUMP

05.05.2021 22:05:36 | Автор: admin

Когда играешь в особенно крутую игру, останавливаться не хочется, пока не пройдешь всё до конца. А ещё хочется создать свою игру! Знакомая история? Для участников DUMP тоже:) В этом году впервые на конференции будет представлена секция GameDev.

Мы решили узнать больше о разработке игр и пообщались с представителями индустрии из компании Targem Games Евгением Бушуевым (Game Designer Crossout) и Алексеем Честных (Creative Director).

Расскажите, как вы попали в игровую индустрию?

Женя: Я заканчивал УПИ, Менеджмент в энергетике и на промпредприятиях. 15 лет назад высшее образование было некой защитой от армии. Дальше я мог пойти по специальности, но этот вариант казался тоскливым. И как-то раз я увидел на ag.ru новость о том что в Екатеринбурге есть студия Targem. Хотел устроиться здесь менеджером, но после интервью меня взяли геймдизайнером. Это было супер предложение! Диплом менеджера я получил уже позже, через год. Но на момент собеседования переживал, что заветной корочки не было.

Алексей: Начну издалека. Я с детства был повернут на видеоиграх. Просто был маньяком, зависал при виде любой анимированной гифки. Кажется, пугал этим родителей. Помню, ездили в Москву, и там в Парке Горького был вагончик с игровыми автоматами, 16-битными. Тогда я попал в рай. Изучал, как что работает. Пиксельное безумие! У меня был компьютер Spectrum. Я пытался делать на нем пиксель арты.

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

Как я сюда попал? Ну, наверное, не то чтобы случайность. Я получил высшее образование, филологическое, и собственно, до этого никогда не работал, жил в своем мире эльфов. Через полтора года после выпуска нашел объявление о том, что Targem Games набирали сотрудников.

Знакомая многим игра X-COMЗнакомая многим игра X-COM

Какая игра, на ваш взгляд, является иконой геймдизайна?

Женя:

Они сменяются, их же много на самом деле. Какой-то одной совсем нет. Я X-COM любил классический очень часто к нему возвращался. Очень важная для меня игра.

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

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

А так выглядит DisciplesА так выглядит Disciples

Алексей:

Я соглашусь с Женей. Это, конечно же, X-COM, причем второй. Я до сих пор помню звуки стрельбы пушек и гибели инсектоидов. Цикличность мне очень нравилась и это вылилось в то, что я до сих пор люблю игры с петлями в геймплее. По началу из икон были X-COM, Герои Меча и Магии вторые и третьи.

Еще в детстве я открыл для себя эмуляторы, а в особенности, игру Chrono Trigger. Она перевернула мой мир. Я помню, что сидел и играл в неё двое суток без остановки!

Вот две игры, которые являются для меня иконами Chrono Trigger и (внезапно) Front Mission 3. Это лучшая игра про роботов, в принципе. Очень дорогая, с прекрасными роликами и сюжетом.

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

А какая топовая игрушка была топовой для Spectrum?

Алексей:

Конечно же, Элита. Тогда производили впечатление такие игры как Саботаж. Там, где был крупный персонаж, во весь рост это производило впечатление. Еще там был первый Wolfenstein вид сверху. The Verse тоже была классная та в которой робота строишь.

Персонаж из игры СаботажПерсонаж из игры Саботаж

Какую роль геймдизайн играет в разработке игр? В чем ежедневный труд и какие бывают типы?

Женя:

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

Алексей:

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

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

А откуда появляются геймдизайнеры?

Женя:

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

Второй путь это много играть. Просто разбирать игры и понимать как они сделаны, почему они так сделаны. Третий пользоваться чужими разборами на YouTube. Это кажется идеальным форматом в наше время.

Алексей:

Геймдизайнер товар штучный и редкий. Как бы ни художник, ни программист. Нужен толковый человек, который играет в игры. В последние годы ситуация улучшилась благодаря тому, что появились курсы и бесплатные движки. Сейчас самое удобное время для разработки Unity и Unreal копеечные. Самые удобные инструменты.

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

Возраст у геймдизайнера имеет значение?

Алексей:

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

Как последний год изменил индустрию?

Алексей:

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

В Targem изменилось то, что мы ушли на удаленку, как и многие. В офисе могли находится только новички, которые проходили свой первый срок, и их наставники. У нас были большие перемены в организации труда. Это пошло нам на пользу.

Какие практики помогают сохранить эффективность?

Алексей:

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

Некоторые игры достаточно долго делают. Как угадать с тем, что будет релевантно и актуально через несколько лет?

Алексей:

Я боюсь, что правильный ответ ты можешь не угадать. Нет инструментов, чтобы заглянуть в будущее. Нужно принимать риски и делать соответствующие решения. Индустрия игр это heat-driven индустрия, как кино. Выходит 1 000 игр из которых, одна игра получает всё, 9 в топе получают половину, а остальные ничего. К сожалению, так это работает. Есть пул игр, из которых что-то может выстрелить. Нет никаких гарантий.

Мы, Targem, старались следовать за трендами, но ничего не получалось. Тренды нужно создавать. Мы начали создавать казуалки, когда они были на подъеме, а закончили, когда уже весь интерес к ним утих. Надо рисковать, делать что-то смелое. И делать то, к чему душа лежит. Ради денег ничего не выйдет.

Женя:

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

Где баланс между чистым творчеством и коммерческим проектом, зарабатыванием денег?

Алексей:

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

Есть в Targem практика свободных дней? В которые кто-то пилит свои проекты или занимается творчеством?

Алексей:

У нас пару лет проводится неделя свободного творчества. Где люди могут свои старые таски пособирать, что-то еще поделать. И в рамках таких недель некоторые фичи могли быть добавлены в игру. Это не очень системно. Мы пока в другой психологии все напряженные, нужно выполнять план, делать новые фичи. Наверное, мы потихонечку будем внедрять эту тему. Хочется больше делать для того, чтобы атмосфера была творческая.

Кто из гейм-дизайнеров ваш топ?

Женя:

Я скорее назову студии, а не людей. Потому что я точно не знаю, кто у них занимается дизайном. Мне очень нравится студия Klei, они выпускают разные игры. Они продуманные, красивые, расширяют пространство этого жанра. Как пример, назову Invisible, Inc.. Я больше всего с ней времени провел. Последнее у них Griftlands, Ninja Mark, Dont Starve, Dont Starve Together.

Кодзиму я не то чтобы люблю, но отношусь к нему с большим уважением.

Самое большое впечатление за последнее время произвел Disco Elysium, это студия ZA/UM. Они при этом из нашей культуры. На одном из награждений благодарили Маяковского и Цоя. Это очень круто.

Алексей:

Мой любимый дизайнер Тим Шейфер. Мне нравится то, что он сам делает визуальный арт и дизайн игр. Мне нравятся инди-игры. Например, создатель Undertale. Создатели Hades Supergiant Games. Они тоже иногда раздвигают жанры.

Создатели FTL Subset Games; они создали целое поколение последователей.

Griftlands от студии KleiGriftlands от студии Klei

Какой был самый громкий фейл?

Женя:

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

Алексей:

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

Чем больше всего гордишься?

Алексей:

Ex Machina. Я считаю её своим полностью проектом. У меня есть ощущение, что она получилась именно такой, в основном, из-за сценария. И, наверное, Crossout. Это черный лебедь. Никто не знает, почему оно работает. Что-то получилось, непонятно благодаря и вопреки. Но этот проект прямо хороший.

Ex Maсhina от Targem GamesEx Maсhina от Targem Games

Еще у нас была ключевая игра, с которой мы вышли на консоли Armageddon Riders. Это был Sledgehammer, который сам по себе противоречивая игра. На его движке за полгода мы сделали Riders. На PC игра прошла мимо, а вот на консолях вышла хорошо и мы смогли заработать.

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

Спасибо ребятам за такую подробную беседу! Надеемся, тебе было интересно. А сейчас немного деталей конференции и секции GameDev:

14 мая в секции GameDev выступят 7 спикеров. Их можно услышать офлайн и онлайн, задать вопросы. Подробнее о программе https://dump-ekb.ru/gamedev

А в бесплатном стриме с конференции в рамках секции выступит Марина Бондаренко. Ее доклад Гиперказуальные игры. Обзор сделок и рынка смотри по ссылке в нашем телеграм-канале https://t.me/DUMPOnline. Ссылку на трансляцию опубликуем там 14 мая.

Подробнее..

Практики DevOps от магии к инструментам. 11 спикеров и одно интервью конференции DUMP

12.05.2021 00:10:39 | Автор: admin

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

В этом году на конференции мы решили сфокусироваться на реальных кейсах, которые не первый год с помощью DevOps развивают продукты и сервисы. Спикеры DUMP готовы поделиться своими примерами, подходами и метриками. От магии, какой казался DevOps некоторое время назад, перейдем к реальным инструментам. В этом нам помогут спикеры:

  • Виктор Еремченко (Miro). Он расскажет про Cloud native vs self-hosted solutions при масштабировании инфраструктуры. Что выбрать? Опыт Miro

  • Александр Тарасов (ANNA Money) и его доклад Не Helm'ом единым

  • Кирилл Казарин (DINS) с темой 4 золотых сигнала на службе SRE инженера

  • Виталий Хабаров (Экспресс 42) готовит доклад Как измерить DevOps?

  • Руслан Тагиров, Чесноков Никита, Бендин Максим (Ростелеком ИТ) и Платформа Цифровых Продуктов Ростелекома. Как развивать DevOps-инфраструктуру в "матером энтерпрайзе"

  • Димитрий Сугробов (Леруа Мерлен) выступит с докладом Dev.+Ops или строим идеальный процесс поставки

  • Артём Картасов (Postgres.ai) и тема Без отката до рассвета: автоматическая проверка PostgreSQL миграций в CI

  • Владимир Лила (Контур) и его доклад Пишем надежные ansible роли. Этот доклад будет в открытом доступе - он включен в программу бесплатного стрима с конференции. Как 14 мая послушать Владимира и других спикеров, рассказали здесь.

Кстати, на прошлой конференции Владимир Лила и его доклад Эластик весом с петабайт вызвал большой интерес и отличные отзывы:

  • Еще один спикер секции DevOps - Дмитрий Харламов (Provectus) и его Долгий путь от bash до gitops. Об этом мы поговорили подробнее. Вот, что Дмитрий рассказал о своих проектах и докладе:

У нас в Provectus множество различных проектов: от типовых, до очень необычных. Зачастую запуск проекта, а тем более стартапа, без знаний бизнеса или без понимания конечной инфраструктуры (а если еще и ТЗ меняют на ходу) - боль. Боль, как для Ops команды, так и для Dev. Необходимо быстро реагировать на ситуацию, иметь возможность расширить\сократить\заменить людей на проекте или стек целиком. Но что бы ни случилось, требуется сделать хорошо и соответствовать определённым стандартам.

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

Взяв за основу наработки одного из наших DevOps инженеров (это был многим знакомый Terraform), мы создали инструмент, который позволял развернуть базовую инфраструктуру в AWS с упором в EKS, и что немаловажно, удалить все созданное без остатка. Мы решили назвать проект Swiss-Army-Kube.

Расскажи нам подробнее, о чем будет твой доклад? Почему ты выбрал именно эту тему?

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

Что подтолкнуло к созданию Swiss-Army-Kube и почему вы решили сделать проект открытым?

Задумка создать такой проект была в компании давно. У нас большой опыт и много инженеров (а это та самая база, на которой хочется построить подобный инструмент). Мы сделали его открытым, потому что это часть маркетинговой стратегии. Мне же близка идея, что знаниями нужно делиться, улучшать свои проекты и помогать другим. Такой айти-коммунизм во всей красе.

Чем занимается Provectus? Расскажи о самых необычных проектах и своей работе в компании

Основное направление - это консалтинг в сфере ML/AI. Мы помогаем запускать стартапы, разрабатываем ПО под заказчиков.Из необычных проектов могу назвать Hydrosphere.io. Это дивный мир machine learning. До встречи с ними я слышал, что есть математики, они тренируют модели, гадают на цифрах...И в общем, я был прав.

Как на работу команды повлияла пандемия?

Тут все очень индивидуально. Кто-то стал больше работать удаленно, кто-то не поменял свой привычный график. Были непростые моменты, когда поговаривали об отпусках за свой счет. Но Provectus всегда открыто заявляет, что ее самый важный актив - это команда профессионалов. Поэтому компания делает все возможное, чтобы сохранить команду. Это классно!

Какие тренды в DevOps появились за последний год?

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

Что бы ты сказал компаниям, которые не понимают необходимость применения практики DevOps?

А такие еще есть?:) Рынок диктует жесткие правила и практики DevOps нацелены на непрерывность процесса, гарантию чистоты кода. Да, это не серебряная пуля и зачастую компаниям приходится ломать устоявшиеся процессы, привыкать к новому - это может усложнять работу. Но стоит понимать, что гиганты рынка Netflix, Amazon, Google уже давно применяют эти практики и в целом довольны. Тем, кто не готов взять процесс трансформации в свои руки, рекомендую обратиться к компаниям, которые на этом специализируются. Как говорится, не попробуешь - не узнаешь.

Работа с бизнес-задачами учит быстро реагировать на изменения рынка, подстраиваться под заказчика, строить работу в команде. Какие хард скилы необходимы DevOps-инженеру и какие софт скилы приобретаешь со временем?

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

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

Как долго выстраивается работа в команде, с чего начать и каких ошибок лучше не допускать?

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

С чего начиналась твоя карьера?

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

Какие проекты вдохновляют лично тебя?

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

Представь, что ты вернулся на 10 лет назад в прошлое, что посоветуешь себе?

Выучи уже этот английский, слабак!:)

А кем видишь себя еще через 10 лет?

Это самый стремный вопрос на всех собеседованиях. Сложно представить. Наверное, всё тот же я, ищущий ответы, но более авторитетный, с горящим взглядом и новыми идеями.


Подробнее..

Практики хорошего code review, или что такое code review за 15 минут. Доклад Никиты Соболева на DUMP в Казани

16.07.2020 22:12:04 | Автор: admin

В 2019 году на DUMP в Казани выступал Никита Соболев технический директор компании Мы делаем сервисы. И Никита на протяжении почти 40 минут пытался вскипятить мозги слушателей секции Backend, рассуждая о code review. Сегодня хотим привести расшифровку этого взрывного доклада, чтобы если уж мозги бурлили, то у всех сразу :)


А вот, кстати, и сам Никита Соболев во время своего выступления.




Для удобства вот ссылка на презентацию.
Доклад начался с постановки того, о чем же он будет. И внезапно прозвучала фраза: Я не буду рассказывать о code review. Доклад будет про хардкорные технические инструменты и методы автоматизации. Главный тезис если вы делаете code review, то вы уже проиграли. Интригующе звучит? :) Давайте вместе с Никитой разбираться, что же за этим стоит.


За основу были взяты понятия, которые предложил американский писатель Карлос Кастанеда, делание и неделание. Что же это значит? Делание это привычка, внутри которой мы существуем. Эдакое хомячье колесо. А неделание взгляд на те же самые вещи, но под другим углом. Никита ловко наложил эти понятия на просмотр кода. И получилось, что мы имеем делание code review и, соответственно, неделание code review. Вот как раз последнему и посвящен доклад.


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


Но для начала нужно разобраться, почему же все так плохо с code review?


Когда ты узнал, что есть code review, то начинаешь пытаться решить все проблемы с его помощью. А проблем на самом деле очень много, как и целей. Какие же цели ставят перед code review?


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

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


Обучение людей с помощью code review.


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


Решение: маленькие задачи. Вы можете дать новичку сразу что-то важное, но при этом небольшое. Это ускоряет обратную связь, увеличивает вероятность найти косяк в коде. Ведь чем массивнее код, тем сложнее поиск ошибок говорит статистика. Под маленькими подразумеваются задачи от 15 минут до 2х, максимум 4х часов. Соответственно, это все предполагает наличие онбординга и хорошей документации. За примером хорошего онбординга (без нудного code review по неделям) идем на Open-Source. Что у них есть? Чек-лист:


  • Contributing.md документ, в котором описаны самые верхнеуровневые шаги;
  • Developer Docs документы с описанием всех api-методов и вообще всего;
  • Architecture Decision Records история решений, принятых по поводу архитектуры. Очень помогает въезжать в процесс новичкам;
  • Wiki с ответами на популярные вопросы;
  • База данных задач и pull requests;
  • И главное понятные для людей тесты.

Если ваш онбординг построен как-то не так, то вам есть куда расти, потому что на Open-Source люди стремятся вот к этому.


Для вдохновения Никита предлагает ряд хороших мест:


  1. Gatsby.js одна из лучших и самых быстрорастущих по количеству контрибьюторов систем, которая описала вообще все;
  2. Dev.to сайт со статьями, документцией, видосами и т.д. У них тоже все прекрасно;
  3. Wemake-python-styleguide творение, к которому сам Никита относится, и по его словам большое количество новых контрибьюторов и довольно мало ошибок.

Перейдем к обсуждению следующей проблемы review архитектуры. Обычно оно корявое. Какие с ним могут быть проблемы?


  • Долго. Когда мы говорим о том, что у нас есть review архитектуры, то это значит, что человек должен пойти и подумать, написать, все перерефакторить и через месяц прислать нам pull request. И как мы будем его ревьюить? Естественно, никак.
  • Дорого переделывать.
  • Участвует один человек.

Решение: проектировать и прототипировать design до review. Design до review это когда вы делаете не саму архитектуру, а ее скелет. Текстом или фиксируете в каком-нибудь файлике. Человек по скелету сможет сказать нравится\не нравится. Это намного быстрее и эффективнее, чем code review в данном смысле.


И, конечно, автоматизация! Никита рассказал о том, как можно автоматизировать архитектурные проверки.


В каждом приложении есть слои (тут, кстати, Никита проводил аналогию с офигенным бургером). И чтобы проверять их есть все возможности. Далее примеры пойдут на языке python.


  • Есть такая штука называется importlinter. Она умеет проверять вашу архитектуру на основе ваших импортов. Когда вы делаете импорт, значит, эти два модуля связаны между собой. Эта связанность и проверяется. Как это делается? Указываете название вашего пакета, после этого вы определяете тип контракта. Все абсолютно декларативно, без кода. Это все текстовый файл. У нас есть такое то имя, вот такой-то тип контракта, который называется layers. И мы будем проверять пакет django_project. У него есть слои: urls, views, forms, models, logic. Соответственно, logic может импортировать ничего. Models могут импортировать logics. Forms могут импортировать models и logic и так далее.



  • Мы можем проверять независимость наших модулей. Часто нам не просто важно определить, что пакеты лежат по разным слоям, но что они лежат на одном уровне. Делается все то же самое, что и в случае со связанностью.



  • Проверка абстракций, которые не должны перетекать. Например, у нас есть логика. И логика чистая, которая не знает ни про какие джанги, фласки или любые другие ваши пакеты. Она просто работает с какими-то абстрактными классами, функциями и т.д. Тогда выборочно запретите импортировать.



  • Для более сложных случаев, когда вот здесь можно, а здесь нельзя, а сверху еще требуются дополнительные проверки напишите свой контракт. Есть api, вы пишите свой контракт готово!

Таким образом можно ревьюить архитектуру автоматически.


Следующая проблема неповторение грабель.


Часто code review нужен для того, чтобы показать новым разработчикам, что мы так уже делали. Как правило, приходится потом повторять как попугай одно и то же. Решение: документация и регрессионное тестирование.


В понимании нашего чудесного докладчика, хорошая документация это когда вот так.




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




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




И теперь другая автоматизация! Часто люди делают ошибки не только в коде. Для решения этой проблемы есть замечательный проект Danger. С ним схема будет выглядеть вот так:




На 2020 год danger-правило можно написать на следующих языках: JS, Swift, Ruby, Kotlin и Python. Никита в своем докладе привел примеры на JS.


Валим CI проверки:


  • Pull request не в мастере, а надо в мастер.
  • Pull request не мерджится из-за конфликтов.



Предупреждающие проверки:


  • Pull request без описания.
  • Забыли указать номер issue в теле.



Так это выглядит в итоге. Здесь исключено человеческое взаимодействие, все автоматизировано.




И еще одна фишечка утилита bellybutton. Она есть для всех языков (проверено Никитой). Допустим, у вас есть некая deprecated_fn(), которую не надо вызывать. Она старая и странная, и существует просто потому что так надо. Вы говорите человеку, чтоб не трогал ее, но он все равно трогает. Когда-нибудь надоест это повторять, и тогда вы берете декларативный файл формата yaml и пишите:




Декларативный файл можно поместить в репозиторий, описать там все правила для текущего проекта и больше человеку по code review не говорить об этом вообще никогда.


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




Почему все так? Во-первых, люди не умеют писать код. Загвоздка в том, что человек должен писать понятно и для другого человека, и для компьютера, а последние два говорят на разных языках. Отсюда и большая сложность. Во-вторых, эта сложность быть понятным для всех и сразу постепенно накапливается. В-третьих, скрытость метрик. Чтобы проверить качество кода, нужно сначала вывести метрики куда-то на экран, посмотреть все это дело, а затем еще долго исправлять. Именно поэтому проблема качества кода это очень и очень серьезная проблема, и к ней нужно подходить с самого начала проекта. Решение: самый жесткий линтер из доступных. Чаще придется писать свой: под разные языки + существующий может быть недостаточно строг. Как говорит Никита: чем больше вы ненавидите линтер, тем он лучше.


Проблема баланса кода и архитектуры. Тут могут возникать такие ситуации:


  • При слишком сложной архитектуре приложения перестаешь понимать, что происходит и куда писать наш код;
  • Архитектуры много, а кода 20 строчек;
  • Наоборот, кода много отсюда сложность работы с ним.

Решение: Architecture on Demand. Оно позволит писать ровно столько архитектуры, сколько нужно. Простая архитектура и простой код под текущую ситуацию. Подробнее Никита этот способ разобрал здесь.


И last but not least проблема контроля выполнения. Обычно говорят, что контроль выполнения это, когда code review, прогон всех тестов, запуск на компьютере, но нет. Перед нами встают проблемы:


  • Я не умею запускать код в мозгу;
  • Я не знаю что, нужно клиенту;
  • Не все нюансы понятны из кода.

Решение: BDD (эффективный способ общения и с заказчиком, и с программистами, и с кем угодно) и Review Apps. Последнее нужно для посмотреть глазками, потому что мало просто прогнать тест. При таком подходе вы сможете сделать ревью уже задеплоенного приложения. Например, использовать ZEIT для GitLab. Так появляется возможность получить на каждый pull request версию приложения.


Только тогда, когда вы прошли все тесты, клиент посмотрел и сказал, что это то, что нужно, вы сами посмотрели, что это работает, можно сказать, что задача выполнена. В итоге получается, что это все не про code review. Код еще даже никто не смотрел.


А теперь подведем итоги. Были разобраны все обозначенные проблемы. Как можно увидеть, ни одна из них к code review отношения не имеет. Для каждой из проблем есть свое целевое решение. Зачем тогда нужно code review? Code review нужно для контроля корректности автоматики. Автоматики у нас полно. Она, естественно, сбоит. И нам нужно глазами проверять, что человек при ней сделал неправильно.


Инструменты, о которых мы говорили:


  1. маленькие задачи (от 15 мин до 2ч., max 4ч.);
  2. review apps чтоб контролировать исполнение;
  3. суровый статический анализ, чтоб проверять качество кода и вообще все, что с ним связано;
  4. строгие архитектурные правила, которые будут декларативно описаны, чтобы четко понимать, где и что мы делаем;
  5. глаза человека как самый последний рубеж. То есть пока не пройдет вся автоматика, на review код даже не попадает.

А нужно ли тогда код вообще смотреть, спросите вы? Ответ конечно, ведь нужен контроль некоторых нюансов:


  • корректность имен;
  • проверка гипотез;
  • проверка общей адекватности.

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


Заревьюить доклад своими глазками можно тут :)


А вы что думаете по поводу философского взгляда на code review?


P.S. Как организаторы DUMP`а хотим выразить благодарность Никите Соболеву за классный доклад :) Надеемся увидеться с ним, и с нашими участниками на DUMP 2020 в Екатеринбурге 20 ноября.


Подробнее..

Современный фронтенд без ошибок и костылей. 8 полезных докладов конференции DUMP

20.04.2021 22:19:53 | Автор: admin

Привет, Хабр!

На связи IT-конференция DUMP и программный комитет секции Фронтенд: Полина Гуртовая (frontend-разработчик в Evil Martians) и Егор Ходырев (тимлид, full stack-разработчик в Кнопке)

Кто согласен, что современный фронтенд это сложно? Ради чего мы мучаемся с настройкой Webpack? Почему реализация SSR требует писать столько кода, и нужен ли он нам вообще такой ценой? Кто виноват и что мы, как разработчики, можем сделать?

В этом году вместе с нашими спикерами постараемся максимально чётко ответить на эти и сотни других вопросов в секции Frontend.

Со своими идеями и решениями выступят:







Алексей Охрименко из Яндекс.Музыки выступит с докладом ''Трасси... что?''

Отладка приложения занимает 99% нашего времени. Кто-то пользуется Chrome DevTools, кто-то обходится обычным console.log, кто-то использует профайлеры. Зачастую этих инструментов более чем достаточно. Но есть еще один, не особо известный и популярный в JavaScript мире.
Трассировка процесс пошагового выполнения программы. В режиме трассировки программист видит последовательность выполнения команд и значения переменных на данном шаге выполнения программы, что позволяет легче обнаруживать ошибки.

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







Григорий Петров из Evrone представит доклад ''Нужен ли нам N(e/u)xt.js?''

Современный фронтенд это сложно. Если легаси проекты ограничены, то для новых приложений, кроме настройки Webpack и Babel, у нас есть HMR, SSR, code splitting, routing, кеширование, stream rendering и это, не считая фронтенд фреймворка и бэкенда, CI/CD и деплоя.

HMR "ломается" на приложениях сложнее hello world, настройку SSR в интернетах хором называют "адски сложной", ну, а роутинг, в уважающей себя связке фронт+бэк, можно неправильно организовать десятью конкурирующими способами.

Вся эта сложность породила новое направление jamstack, и такие решения, как Next.js и Nuxt.js "opinionated фреймворки", где все настроено за нас.

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








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

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







Андрей Гончаров из Hazelcast и тема его доклада, которая звучит так: Lifting state up is killing your app.

Слышали ли вы про lifting state up? Может ли одна из двенадцати ключевых концепций в официальной документации React приводить к плохой производительности? В рамках доклада мы сделаем простейший grid на React. Поэтапно разберем возникающие проблемы производительности. Увидим, что иногда и O(1) - это недостаточно быстро. Будем профилировать и рефакторить до тех пор, пока приложение не станет работать быстрее, чем вы успеете сказать React.






Леонид Семенов из InvestEngine выступит с докладом про Е2Е тесты в браузеры. Когда Cypress, а когда не очень.

Что делать если ошибки в проде смертельны, а релизы идут каждый день?
Как спастись от бессонных ночей, панической боязни сломать прод, и не страдать при этом от тестирования?

Ответов может быть много, но, кажется, что очевиден один автотесты!
Как внедрить автоматизированное сквозное тестирование?
О двух внедрениях, двух инструментах, одном путешествии, проблемах по пути и о самом пути вы тут и узнаете.






Роман Лысов из Semrush расскажет, ''Как создавать React компоненты, которыми будет приятно пользоваться''.

Проблема кастомизации компонентов и их использовании друг с другом всегда болезненна, и в компании Semrush решили эту проблему.
Доклад Романа основан на 4-х летнем опыте создания дизайн-системы для большого числа разработчиков. Он расскажет про практические приемы и паттерны для написания общих компонентов, которые помогут сделать ваш API компонентов более гибким, понятным и предсказуемым, что в итоге сэкономит многие человеко-часы на обслуживании в будущем.







Людмила Мжачих из Mail.Ru Group в докладе ''Как тестировать фронтенд без тестировщиков и спать спокойно'' объяснит, почему процесс разработки не может обойтись без багов и как сводить их к минимуму. Это становится возможным только когда разработка и тестирование начинают жить вместе.

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









Полина Гуртовая из Evil Martians выступит с докладом ''RTC и Франкенштейн', в котором расскажет об особенностях использования WebRTC для боевых задач, опишет проблемы, которые поджидают разработчиков, и покажет способы их преодолевать.

Услышим и обсудим опыт наших спикеров 14 мая в форматах онлайн и офлайн. Полная программа конференции DUMP и билеты на сайте.

А пока спикеры готовятся к выступлениям, посмотри ТОП-3 выступлений секции фронтендеров с нашей прошлой конференции >>>

1. Виталий Дмитриев и его "Реактивное программирование. Как мыслить реактивно, а не проактивно"

2. Александра Шинкевич поделилась болью разработчика в докладе "Как внедрить стандарты разработки, чтобы никто не пострадал"

3. Вадим Макеев и 15 лет опыта: от создания и экспорта графики до оптимизации и вставки в его выступлении "Делайте из слона муху"

Подробнее..

Как решить нестандартные задачи в Backend и не проиграть. Расскажут спикеры конференции DUMP

29.04.2021 22:15:20 | Автор: admin

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

Ты только посмотри, какие спикеры нам в этом помогут!

Михаил Беляев из Прософт-Системы с докладом Проблемы embedded или как мы от sqlite ушли

При embedded разработке существует очень большая проблема весьма ограниченные ресурсы устройства, на котором выполняется твой код. В ходе разработки, когда запросы клиентов растут, а ресурсы embedded устройства на исходе, очень часто стандартные и проверенные решения не подходят. Разработчик сталкивается с выбором: или сказать, что наше устройство не может справиться с требуемыми задачами, или сделать нестандартный ход и выиграть. Вот именно об этом процессе перехода от использования SQLite к собственному хранилищу данных, которое позволяет читать и писать данные значительно быстрее, Михаил поведает другим разработчикам.

Андрей Цветцих из EPAM представит доклад Чистая Архитектура на практике. Вот что он рассказал нам о своем выступлении:

С момента выхода книги Дяди Боба Clean Architecture прошло уже достаточно времени. Кто-то ее прочитал, а кто-то только смотрел доклады на youtube. Но все эти доклады идейные. У их авторов обычно нет практического опыта создания больших проектов по данной архитектуре (как и запуска этих проектов в production). А все примеры слишком простые! На практике все равно остается много вопросов. Больше года назад мы начали 2 новых проекта, в которых применяли принципы, описанные в книге. Это корпоративные приложения на C# (API, backend). Enterprise, который еще не успел стать кровавым :) Но этого вполне достаточно чтобы получить первые результаты и поделиться опытом.

Роман Неволин из Контура выступит с докладом про Функциональные языки для бизнес-разработки

Функциональные языки зачастую воспринимаются как красивые и модные игрушки посмотреть и повертеть забавно, а вот в суровом энтерпрайзе им не место. Принято считать, что здесь лучше всего подходят проверенные годами, простые и надежные языки, такие как Java. Роман же с этим согласиться никак не может и постоянно пытается применить любимый функциональный язык F# - к очередной бизнес-задаче. На выступлении обсудим, как Роман это делает, зачем оно ему (и всем остальным) нужно, и какие именно грабли он успел собрать на пути.

Кстати, Романа можно будет услышать в нашем бесплатном стриме, о котором мы подробно рассказали здесь.

Евгений Пешков из JetBrains с докладом Клиентский HTTP в .NET: дорога по граблям от WebRequest до SocketsHttpHandler

На первый взгляд кажется, что отправить HTTP запрос это очень просто. Тем не менее, даже HTTP/1.1 достаточно нетривиален RFC на него содержит более 150 страниц, кроме того браузеры уже поддерживают HTTP/2 и HTTP/3. Это не оставляет никакого выбора: стандартный клиент в платформе должен быть реализован на высоком уровне.

На пути от .NET Framework 1.0 к .NET 5 клиентские API для работы с HTTP и его реализации претерпели множество изменений. В некоторых версиях они были удачными, в некоторых же провальными и явно временными.

В докладе Евгений расскажет о истории развития клиентского HTTP API в .NET, его особенностях, о миграции приложений с Framework на Core с их учётом. Также разберет некоторые хаки, полезные при работе с ним. Заглянем в NuGet и рассмотрим представленные в нём обёртки над HTTP API с точки зрения эффективности и кроссплатформенности.

Александр Поляков из Яндекса расскажет Как Яндекс.Афиша 2 раза переезжала на GraphQL

Этот доклад о том, как мы переписали API Я.Афиша с REST на GraphQL на node.js + Python. А затем, в рамках оптимизации, избавились от node.js + Python и переписали весь GraphQL на Java.

Разберемся со следующими вопросами:

почему мы выбрали технологию GraphQL

какие проблемы и задачи решали с ее помощью

расскажем и покажем, как эволюционировала наша архитектура

для каких команд и проектов подходит наше решение, а для каких нет и почему

А также дадим несколько практических советов по тому, как лучше всего начинать работать с GraphQL

Фагим Садыков из SpectrumData представит нам свой доклад Kotlin как основной язык разработки бэкенда и обработки данных

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

В компании SpectrumData Kotlin используется как основной (и по факту единственный) продуктовый язык разработки на платформе JVM для самого широкого круга задач: работа с данными, реализация микро-сервисной архитектуры, реализация бэкенда. История успешного применения Kotlin в компании длится уже 4 года с версии языка 1.1. Для SpectrumData характерно полноценное применение в своей кодобазе всех возможностей и рекомендованных практик по данному языку.

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

Про Аспектно-ориентированное программирование на C# и .NET вчера, сегодня и завтра расскажет Денис Цветцих из Invent

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

В своем докладе Денис поделится 10-летним опытом использования АОП на C# и .NET. Расскажет о подходах к реализации АОП, а также покажет, как менялись инструменты для разработки аспектов вместе с языком программирования и платформой. Естественно, он предложит наиболее оптимальный на сегодня вариант реализации аспектов. И вместе подумаем, какими хотелось бы видеть инструменты для разработки аспекты в будущем. Примеры будут на C# и .NET, но идеи доклада будут актуальны для любой платформы.

А под занавес программный комитет поставил Антона Шишкина из SKB LAB с докладом Рекомендации и фичи первой свежести . Здесь Антон расскажет про свой опыт построения рекомендательной системы от offline расчетов до online. И отдельно про то, как обеспечивается актуальность фичей для онлайн расчетов. Будут разобраны "допущения", благодаря которым фичи сохраняют свою "свежесть", при этом обеспечивается высокая доступность хранилища признаков.

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

А здесь можно выбрать билеты в онлайн и офлайн формате.

Подробнее..

Боли менеджера. Обсудим опыт, факапы и успехи в секции Product на DUMP-2021

08.04.2021 14:12:31 | Автор: admin

Начинаем рассказывать детали про секции DUMP. Встречайте впервые на конференции будет отдельная секция Product.

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

Поэтому у нас появилась отдельная большая секция - 8 спикеров, 320 минут концентрированной пользы (с перерывами, конечно :) и общением.

О чем мы будем говорить?

  • О продуктовых компетенциях: какие хардскиллы и софтскиллы нужны продактам (и продуктовым командам!) в зависимости от целей

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

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

  • Поговорим и про тренды. Про поколения Z и А - вы задумывались о них? А продукты для них создаете? А планируете? Это не просто абстрактные вопросы, это интересная тенденция развития рынков, о которой стоит подумать уже сейчас, чтобы через несколько лет быть на коне. Инсайты гарантированы!

Для кого эта секция?

Для всех, кто развивает продукт!

Это продуктовые/бизнес аналитики, продакты и те кто хочет им стать, менеджеры по развитию продуктов, product owner'ы, владельцы собственного бизнеса или носители стартаперских идей. Полезно и интересно будет всем!

Нам самим уже не терпится послушать выступления и задать вопросы.

Билеты на офлайн и онлайн уже на сайте!

Присоединяйся к DUMP-2021!

Подробнее..

Разбор секции DESIGN на DUMP куда расти и развиваться?

12.04.2021 20:16:10 | Автор: admin

Дизайн - одна из самых заметных и посещаемых секций на конференции DUMP. Здесь стоит вспомнить доклад Алексея Кулакова про обратную связь. На прошлой конференции он затронул очень важные и близкие каждому дизайнеру вопросы:

В этом году нам с вами тоже есть, что обсудить. Поговорим и зоне развития дизайнера.

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

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

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

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

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

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

Присоединяйся к DUMP-2021!Билеты на офлайн и онлайн уже на сайте

Подробнее..

Категории

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

  • Имя: Макс
    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