Никита Дубко — разработчик интерфейсов в компании Яндекс. Помимо работы в Яндексе, Никита участвует в организации англоязычной конференции CSS-Minsk-JS и митапов MinskCSS и MinskJS. На FrontendConf на РИТ++ 2019 Никита выступал с докладом «Алиса, пойдем во фронтенд». В нём описан эксперимент по созданию голосового навыка от Алисы от разработчика, который раньше с ней не работал. Доклад интересен тем, что за время, пока выступает спикер, легко создать такой же навык. Рассказ об Алисе зрители выбрали лучшим на всей конференции.



За плечами Никиты десятки выступлений, на каждое из которых уходят недели. Во время подготовки он изучает много нового материала, тренирует выступления на камеру, среди коллег и друзей, оттачивает сценарий и слайды. Поэтому его доклады интересны, увлекательны и заслуженно получают высшие оценки слушателей. О подготовке к докладам, изменениях в жизни, синдроме самозванца, а также о том как выступать на конференциях, чтобы получить работу в Яндекс, в интервью Никиты Дубко. Это не совсем обычное интервью, а текстовая расшифровка подкаста Frontend Weekend, который ведёт Андрей Смирнов. Что из этого получилось, читайте под катом.

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



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

В один пасмурный летний день, после посещения секции от авито на РИТ2017, до меня вдруг дошло, что хайп по поводу докера не смолкает уже пару лет и пора, наконец, уже его освоить. В качестве подопытного для упаковки был выбран dotnet core+C#, т. к. давно интересно было посмотреть, каково это — разрабатывать на C# под Linux.

Предупреждение читателю: статья ориентирована на совсем новичков в docker/dotnet core и писалась большей частью, как напоминалка для себя. Вдохновлялся я первыми 3 частями Docker Get Started Guide и неким блог-постом на english. У кого хорошо с английским, можно читать сразу их и в общем-то будет сильно похоже. Если же после всего вышенаписанного вы еще не передумали продолжить чтение, то добро пожаловать под кат.

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

Разработка игры — само по себе непростое занятие. Но мультиплеерные игры создают совершенно новые проблемы, требующие разрешения. Забавно, что у наших проблем всего две причины: человеческая натура и законы физики. Законы физики привнесут проблемы из области теории относительности, а человеческая натура не даст нам доверять сообщениям с клиента.

На конференции HighLoad++ 2016 руководитель разработки «М-Тех» Вадим Мадисон рассказал о росте от системы, для которой сотня микросервисов казалась огромным числом, до нагруженного проекта, где пара тысяч микросервисов — обыденность.

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

Если коротко, то мы занимаемся видеоотдачей — отдаём видео в реальном времени. Мы являемся видеоплатформой для «НТВ-Плюс» и «Матч ТВ». Это 300 тысяч одновременных пользователей, которые прибегают за 5 минут. Это 300 терабайт контента, который мы отдаем в час. Это такая интересная задача. Как это всё обслужить?

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

Эта статья представляет собой синтез пятилетнего опыта работы консультантом в области корпоративного документооборота в среде SAP. Мой опыт ограничивается только одним вендором — OpenText (Канада), но в последние годы эта технология становится все более и более популярной, в связи с чем и появилось желание опубликовать этот материал.

В статье описана технология работы с неструктурированными документами (сканы документов, электронные оригиналы в формате MS Office и т.д.) в среде структурированных электронных документов — транзакций SAP. Описаны как технический аспект, так и основные бизнес-сценарии работы с документами. Публикация будет полезна всем начинающим (и не очень) консультантам по документообороту, работающим на проектах SAP. Материал был написан практически «из головы», в качестве некоей шпаргалки, или методички.

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

История написания бота для Stronghold Kingdoms

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

Да, как Вы могли заметить, C# не спроста – игра написана именно на нем, с использованием .net 2.0, что в последствии вставило мне некоторые палки в колеса.


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

Но мне это показалось нудным и муторным, ведь зачем городить велосипед, если имеются те самые «исходные коды».

Вооружившись Reflector’ом я начал разбираться с точкой входа игры (код которой вообще никак не обфусцирован более трех лет, диву даюсь разработчикам) – ничего особенного.

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

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

Как нам удалось эти бенефиты включить в корзину для участника — читайте под катом.

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

Не будет:
• Классического Unit Test;
• Принижения влияния Code Behind;
• Неожиданных открытий в MVC.

Будет:
• Unit Test и Stub;
• MVC;
• Внедрение подхода на базе существующего продукта.

После завершения создания игры-головоломки на Unity и выпуска ее на Google Play и AppStore, появилось желание поделиться опытом и впечатлениями. И получить конструктивные замечания и предложения, если таковые возникнут

Часть 1
Часть 2

Прежде чем начнем, хочу предложить скрипты переписанные на C#. т.к половина скриптов на JS я решил переписать их под C# (мне C# роднее). Скачать

Так же идет активный «разбор» проекта для начинающих «Project: Survival shooter», видеоуроки представлены в следующем Плэйлисте, дополнительные видеоуроки к Survival shooter. Лично выражаю благодарность этому каналу, за их не легкий труд.

p.s в конце этого руководства есть видео обзор в котором на примерах идет сравнение двух реализованных методов управления автомобилем.

Итак, приступим к изучению нашего руководства.

Часть 3: Под капотом

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

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

Продолжение. Начало здесь.

Как все это использовать?

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

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

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

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

Сразу оговорюсь, что примеры приводятся применительно к языку C# и платформе .NET. Соответственно, в других языках/платформах подходы и реализации могут отличаться.

Итак…

В наших с вами интернетах недавно поднялся нешуточный шум по поводу того, жив ли TDD сейчас, нужен ли он, и в каком виде. Все началось со статьи Дэвида Хансона «TDD is dead. Long living testing», после которой последовали статьи многих авторов и живые обсуждения этой проблемы включая hangout вместе с Дэвидом, Кентом Беком и Мартином Фаулером (кстати, очередной hangout будет завтра, 16 мая).

Но немногие знают, что за несколько дней до этого все тот же Мартин Фаулер постарался дать определение модульного теста (bliki:UnitTest), перевод которого представлен ниже. А после перевода идут кое-какие мои мысли по этому поводу.

Вступление

Вы всё ещё тестируете с помощью JUnit и не обращаете внимания на TestNG? Тогда мы идём к вам.

Одним из преимуществ TestNG является возможность создания тестовых массивов данных для одного или нескольких тестов. Но мало кто использует такое преимущество от @DataProvider как пустой набор тестовых данных. В чём оно выражается?

Допустим у нас есть некий тест testData(String value) и метод datas обеспечивающий DataProvider. Если datas вернёт нам массив из 3-х элементов, то testData выполнится 3 раза. Но если datas вернёт нам пустой массив, то testData не выполнится ни разу
Давайте попробуем воспользоваться данной особенностью.

Примечание от переводчика: мой опыт знакомства с разработкой через тестирование во многом схож с тем, что описывает автор (хотя и начался на несколько лет позже). Я начинал изучать TDD самостоятельно, на работе, исправляя баги и создавая новые модули с нуля. Эффект от применения TDD произвёл на меня настолько мощное впечатление, что породил желание делиться умением применять эту технику с другими. Я также проводил Code Retreat-ы внутри и вне своей компании. И я вижу те же проблемы в своих тренингах — очень сложно взять и «впихнуть» понимание сути TDD в чужие головы.

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

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

TL;DR?

Многие сторонники TDD рекомендуют подход под названием «интенсивная практика», но я догадываюсь, что у Вас не будет возможности тратить много рабочего времени на практику. Я советую людям «применять TDD осознанно», но до сих пор не знал хорошего способа достаточно доступно объяснить смысл этих слов, что снижало ценность моего совета. Вы можете начать применять оба подхода (интенсивный и осознанный) одновременно, если начнёте исправлять баги через тесты. Даже если Вы до сих пор не умеете проектировать софт на экспертном уровне, то, по крайней мере, Вы уже можете учиться как эксперт. И исправление багов через тесты даст Вам естественную и не слишком рискованную возможность делать это. У Вас будет возможность практиковаться в TDD усердно и осознанно. Если у Вас есть возможность исправлять баги на работе в одиночку, то Вы можете использовать эти практики, не привлекая лишнего внимания, которое обычно возникает при разговорах об «интенсивной практике». Просто говорите всем, что Вы исправляете баги. Это всем понравится.

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

От переводчика. Давид Хейнемейер Ханссон данной статьей поднял острую тему обязательности использования TDD и, даже, возможного вреда от написания тестов перед написанием кода. Именно эта статья послужила лейтмотивом уже пяти встреч на тему жив ли TDD, на которых Давид, Кент Бек и Мартин Фаулер обсуждают достоинства и недостатки TDD, рамки применимости и ограничения. Для тех у кого восприятие устного английского оставляет желать лучшего, SergeyT публикует краткие саммари в своем G+.