Привет, Хабр! представляю вашему вниманию перевод статьи «How To Build A Great Technical Portfolio» автора Emma Wedekind.

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

Предлагаю вам взглянуть на несколько моих советов по созданию идеального технического портфолио.

Заметьте: эти советы построены на моем личном опыте. Существует множество способов составить отличное портфолио, так что используйте их как рекомендации, а не как жесткие правила.

Дисклеймер

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

1. Структура доклада

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

Ключевая проблема для слушателя – отсутствие вводной части. Выводы он может сделать и сам, а вот стартовать с опозданием сложно и неприятно. Он ещё не понял, что вы будете про пищеварение, а уже нужно вникать в строение эпителия тонкого кишечника. Результат – ваш доклад попадает в слушателя не на все 100%, а имеет шансы и вовсе пролететь мимо.

Когда я составляла свое первое резюме, процесс отбора на очное интервью мне казался магией. Люди, принимающие решения, представлялись «черными ящиками», которые определяют: кандидат «интересен» или «неинтересен» — по непонятным критериям.

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

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

В этой статье я хочу рассказать:

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

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

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

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

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

Немного прошерстив Habr удивился тому, что очень мало опубликовано статей на тему (beta-)фичи GitHub'а — Actions.

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

Процедурная генерация используется для повышения вариабельности игр. Среди известных проектов можно упомянуть Minecraft, Enter the Gungeon и Descenders. В этом посте я объясню некоторые из алгоритмов, которые можно применять при работе с системой Tilemap, появившейся как 2D-функция в Unity 2017.2, и с RuleTile.

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

О чём этот пост?

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


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

Уже более 10 лет я работаю гейм-дизайнером в очень успешных компаниях (старшим гейм-дизайнером в Matific, ведущим гейм-дизайнером в TabTale, владельцем Lookandfeel Games), и всё это время обладал привилегией и возможностью использования данных, полученных от сотен миллионов пользователей со всего света. Настало время поделиться моими знаниями с миром.

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

«Жаль вас разочаровывать, но ваша идея не сработала».

Разочаровывать? С какой стати! Спасибо за то, что дали мне возможность переосмыслить свой дизайн, чтобы я не заблуждался в его правильности. Как иначе бы я мог совершенствоваться? Как иначе достигнуть мастерства? Благодаря анализу данных хорошие идеи дублируются и применяются в моих следующих проектах, а «пробные шары» в соответствии с ним улучшаются или отбрасываются. Вот «библи»я моих рекомендаций с уроками, почерпнутыми из 250 с лишним игр. Данные подтвердили, что они повышают монетизацию, удерживание игроков (retention), игровой процесс и вовлечённость (engagement).

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

Можно ли всё это как-то ускорить?!

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

Этот способ называется SPLATTER TILE!

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

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

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

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

Agones (от др.-греч. agōn — «соревнование») позволяет развернуть кластер игрового сервера используя Kubernetes с возможностью Auto-Scaling. Этот open-source проект был создан в 2018 году, уже набрал 2500 звезд, был на Google I/O 2019, и на Хабре, к великому удивлению, еще не был упомянут. В топике описан краткий экскурс в архитектуру и инструкция по запуску тестового сервера на локальной машине. Если интересно, добро пожаловать под кат, вперед!

В мае 2019 года GitHub анонсировала выход сервиса Package Registry. Вслед за этим, уже в августе, была анонсирована поддержка CI/CD в Actions.

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

Это исчерпывающее руководство по обеспечению надёжности в JavaScript и Node.js. Здесь собраны десятки лучших постов, книг и инструментов.

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

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

Читая чат русскоязычного react сообщества в телеграмме (https://t.me/react_js), я вижу как с постоянной регулярностью появляются обсуждения mobx-а, сравнения с redux-ом с аргументациями про магию, сложность и "мутабельность" и у многих есть большое недопонимание что такое mobx и какие задачи он решает. И я решил написать эту статью с "разбором полетов" чтобы можно было собрать всю аргументацию в одном посте. Мы разберем как работает mobx изнутри путем реализации собственной версии mobx-а и сравним с тем как работает redux.

От переводчика:

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

---

С момента выхода нового Context API в React 16.3.0 многие люди задавали себе вопрос, достаточно ли хорош новый API, чтоб рассматривать его как замену Redux? Я думал о том же, но до конца не понимал даже после выхода версии 16.8.0 с хуками. Я стараюсь пользоваться популярными технологиями, путь даже не всегда понимая всего спектра проблем, которые они решают, так что я слишком сильно привык к Redux.

И вот так получилось, что я подписался на новостную рассылку от Кента Си Доддс (Kent C. Dodds’) и обнаружил несколько email на тему контекста и управлением состоянием. Я начал читать…. и читать… и спустя 5 блог постов что-то щелкнуло.

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

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

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

Разбиение пространства

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

Способов разбиения пространства тоже очень много: разделение на сетки, двоичное разбиение пространства, разбиение пространства деревом квадрантов, диаграммы Вороного и т.д. Я решил использовать двоичное разбиение пространства, потому что оно хорошо подходит для генерации прямоугольных комнат. Этот метод получил популярность благодаря статье на RogueBasin.

Единственная сложность этого алгоритма — выбор позиции разделения. Если мы не наложим ограничение на позицию разделения, то будем получать странные разбиения пространства:


Такого поведения можно избежать несколькими способами. Один из них — ограничить позицию разделения двумя соотношениями длин сторон, например, в интервале от 30% до 70% или от 40% до 60%. Другой способ — использовать вместо равномерного распределения нормальное или биномиальное, благодаря этому повысится вероятность разделения по центру стороны, а не по краям. Эти способы устраняют проблему, но сложно понять, как конкретно параметры влияют на окончательный результат.

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



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

Как проверить идеи, архитектуру и алгоритмы без написания кода? Как сформулировать и проверить их свойства? Что такое model-checkers и model-finders? Требования и спецификации — пережиток прошлого?

Привет. Меня зовут Васил Дядов, сейчас я работаю программистом в Яндексе, до этого работал в Intel, ещё раньше разрабатывал RTL-код (register transfer level) на Verilog/VHDL для ASIC/FPGA. Давно увлекаюсь темой надёжности софта и аппаратуры, математикой, инструментами и методами, применяемыми для разработки ПО и логики с гарантированными, заранее определёнными свойствами.

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

Не буду лукавить: основная задача статьи — возбудить интерес. Так что в ней будет минимум пространных рассуждений и максимум конкретики.

Автор статьи, перевод которой мы сегодня публикуем, говорит, что сейчас можно наблюдать рост популярности таких сервисов аутентификации, как Google Firebase Authentication, AWS Cognito и Auth0. Индустриальным стандартом стали универсальные решения наподобие passport.js. Но, учитывая сложившуюся ситуацию, обычным явлением стало то, что разработчики никогда в полной мере не понимают того, какие именно механизмы принимают участие в работе систем аутентификации.

Этот материал посвящён проблеме организации аутентификации пользователей в среде Node.js. В нём на практическом примере рассмотрена организация регистрации пользователей в системе и организация их входа в систему. Здесь будут подняты такие вопросы, как работа с технологией JWT и имперсонация пользователей.



Кроме того, обратите внимание на этот GitHub-репозиторий, в котором содержится код Node.js-проекта, некоторые примеры из которого приведены в этой статье. Этот репозиторий вы можете использовать в качестве основы для собственных экспериментов.