Исследования показали: получив конструктивный фидбек, сотрудники работают лучше. Если обратной связи нет, появляется стресс: трудно понять, хорошо ли ты справляешься и куда двигаться дальше. Возникает «кризис признания» – а там не за углом и выгорание.

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

Еще лет 10 лет назад роль архитектора решений (Solution Architect) на проектах выполняли сами разработчики. Теперь это отдельная профессия, довольно востребованная и активно обсуждаемая. Вместе с коллегами-архитекторами подробно разбираемся во всех деталях и рассказываем, как стать архитектором в EPAM.

Когда в детстве мы хотим стать, скажем, врачом или следователем, то едва ли знаем специфику профессии. Похожие ситуации случаются и со взрослыми: представления о работе мечты на поверку имеют мало общего с реальностью. Но как выяснить наверняка, где скрыты подводные камни? Один из способов – поговорить с практиком начистоту! Мы предложили Андрею Трубицыну, который сотрудничает с EPAM в качестве Solution Architect из Java Competency Center, развенчать распространенные мифы о работе архитектора.

Привет, я Катя, я не работаю уже год.



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

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

За полным списком новых полезных инструментов, статей и докладов можно обратиться в мой телеграм канал @OpensourceFindings (по ссылке зеркало, если не открывается оригинал).

В сегодняшнем выпуске.
Технологии внутри: Python, Rust, JavaScript, Go.
Тематика: веб разработка, администрирование, инструменты разработчика.

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

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

Если бы все было так просто.

Что вас ждет? Если коротко:

• - личная жизнь \ + адский труд бесплатно
• - поддержка близких \ + стадо критиков
• - стандарты качества \ + зато оригинально
• - Я всё могу \ + депрессия средней степени тяжести

Этот список можно продолжать бесконечно.

В Playrix приходит много новых сотрудников и большинство из них не работали с Git. Особенно это касается гейм-дизайнеров и художников. Хотя и для программистов это не редкость – опыт работы с другими системами контроля версий не слишком помогает. Например, часто встречается опыт работы с SVN. Но Git заметно отличается по идеологии. Заучить, какие кнопки нажимать, в большинстве случаев не сложно, но шаг в сторону – и уже трудно понять, что происходит.



Поэтому мы решили написать ознакомительный материал. Мы поговорим о системе контроля версий и логике её работы, с самых азов. С Git можно работать с помощью  разных клиентов, потому в статье не пойдет речь об интерфейсе пользователя. Это может показаться непривычным, но это сделано намеренно. Вместо этого мы сфокусируемся на рабочем каталоге, коммитах, ветках, командах pull, push и прочих. Когда вы разберетесь в этих понятиях, вам останется выбрать один из Git-клиентов и освоить его интерфейс.

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

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

Но все они выглядят как куча навоза.

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

Благодаря этой репутации мы провели на Kickstarter успешную кампанию по сбору средств на Queen's Wish: The Conqueror — потрясающую RPG, которая тоже будет выглядеть чудовищно. Мы надеемся, что она станет фундаментом для дальнейшего создания ужасно выглядящих игр.

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

Самое главное заключается в том, что я хочу защитить право инди-разработчиков быть странными. Если у инди-разработчика появится безумная, творческая идея, и он испугается её реализовать, но подумает: «Это можно и сделать; по крайней мере, я не настолько сумасшедший, как Джефф Вогель», то я буду считать свою миссию выполненной.

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

Скриншот из Queen's Wish. Учтите, что я использую игровой арт, который мне нравится. Это необходимо, потому что потом придётся смотреть на него годами, и я не хочу сойти с ума.

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

Спасибо всем! Когда пытаешься привлечь внимание к инди-игре, то плохой славы не бывает.

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

Я получил много вопросов. Хороших вопросов. Почему я не могу позволить себе арт-директора? Сколько стоит графика? Почему бы не сделать то или это? Поэтому я решил написать ещё один пост. Я хочу ответить на хорошие вопросы.

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

Видите ли, я самый большой жмот на рынке инди-игр.

Привет, Хаброжители! Если вам давно кажется, что вся разработка и развертывание в вашей компании донельзя замедлились — переходите на микросервисную архитектуру. Она обеспечивает непрерывную разработку, доставку и развертывание приложений любой сложности.

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

Предлагаем ознакомиться с отрывком «Управление транзакциями в микросервисной архитектуре»

Здравствуйте, коллеги.

Сегодня на ваш суд предлагается перевод статьи Тугберка Угурлу (Tugberk Ugurlu), который взялся в сравнительно небольшом объеме изложить принципы проектирования современных софтверных систем. Вот что автор сообщает о себе в сухом остатке:


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

Здравствуйте, уважаемые читатели.

Предполагаем, что некоторые из вас уже в курсе грядущего переиздания фундаментальной работы Джона Лакоса "Large-Scale C++".



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

Здравствуйте, дорогие читатели!

У нас активно расходится третий доптираж крайне успешной книги «Изучаем C++ через программирование игр». Поэтому сегодня вашему вниманию предлагается перевод интересной статьи на одну из узких тем, связанных с программированием игр на C++. Также просим вас поучаствовать в опросе

Здравствуйте, коллеги.

Не так давно наше внимание привлекла почти готовая книга издательства Manning «Programming with types», подробно рассматривающая важность правильной типизации и ее роль при написании чистого и долговечного кода.



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

Всем привет!

Предваряя сегодняшнюю переводную публикацию, сразу отметим, что этот текст задуман как follow-up недавнему дискуссионному материалу "Прекратите усердствовать с комментариями в коде". Нас настолько впечатлила развернувшаяся там дискуссия и 189 комментариев по состоянию на 19.07.2019, что мы решили дать здесь слово и другому автору с портала Medium (Кристоферу Лейну), который практически по всем принципиальным вопросам полемизирует с тезисами Брайана Норлендера, автора первой статьи. Отметим, что в оригинале данная статья вышла на месяц позже предыдущей (16 мая и 16 июня), но собрала практически вдвое меньше аплодисментов (706 против 1,5K на момент публикации перевода). Посмотрим, что будет на Хабре…



Снимок взят с сайта rawpixels.com от автора Pexels

В нашем первом туториале по ретро-играм мы показали, как настраивать инструмент 2D Pixel Perfect и как создавалась графика в эпоху 8-битных игр. В этом посте мы перенесёмся в 16-битную эру. С помощью Mega Cat Studios мы узнаем, как создавать аутентичную графику для игр в стиле Sega Genesis (Mega Drive) и Super NES при помощи параметров, графических структур и цветовых палитр Unity.

Создание аутентичной графики в стиле Genesis

В этом разделе мы рассмотрим рабочий процесс создания графики, имитирующей картинку разных консолей. Здесь будет меньше ограничений, чем в 8-битном проекте и больше свободы при работе с цветом, но всё-таки у Genesis есть пределы. Мы считаем, что будет также полезно объяснить, как работало «железо» консоли, чтобы вы могли применить эти ограничения в собственном ретро-проекте.

Палитры и субпалитры

Переход от 8-битных к 16-битным консолям благодаря усложнению оборудования предоставил разработчикам больше возможностей. Тем не менее, принципы создания качественной NES-графики всё ещё остаются в силе. Вся графика по-прежнему хранится в тайлах, например, размером 8×8, и собирается из них в большие изображения — спрайты и элементы фона. Художники по-прежнему ограничены субпалитрами с общим прозрачным цветом, но 16 бита обеспечивают бОльшую гибкость работы с палитрами. Вас скорее всего порадует то, что у 16-битных консолей не было жёстко заданной цветовой палитры, то есть по сравнению с NES количество доступных цветов сильно расширилось.

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



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

• Чего может ожидать программа?
• Профилировка использования ресурсов, не являющихся ресурсами CPU.
• Профилировка непреднамеренных переключений контекста.

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

Всем привет! Меня зовут Андрей Киселев, я основатель компании «ЖИШИ СУШИ».

Любой бизнес успешней в местах с хорошей проходимостью, но как найти это место? Рассказываю на личном опыте в статье как сравнивать локации онлайн.



Есть три способа оценки проходимости:

• визуально(много/мало)
• посчитать людей в час
• использовать геотаргетинг

Первые два — это оффлайн методы. Они могут быть необъективны и требовать больших затрат по времени. Геотаргетинг лишен этих недостатков. И основное его преимущество — можно все сделать удаленно.

Об этом способе я и расскажу в этой статье.

Как шумиха вокруг ИИ обогатила инвесторов, обманула СМИ и запутала всех остальных

Статья за авторством Майка Малаццо, выложенная им на сайте Medium, и по неизвестным причинам пропавшая оттуда спустя месяц.

Когда появились новости о том, что McDonalds покупает израильскую «ИИ-компанию» Dynamic Yield за $300 млн, главный редактор Wired Николас Томпсон предсказал, что эта продажа запомнится либо, как «пик шумихи по поводу ИИ», либо как «день, когда биг дата спасли Биг Мак».

Я, как бывший сотрудник Dynamic Yield, считаю, что время покажет, что он был прав в обоих случаях. Если правильно использовать технологии и таланты, то Dynamic Yield окупится много раз, сумев помочь компании McDonald лучше понять её клиентов. Но это не произойдёт благодаря ИИ. И всё же за те два года, что я был в этом стартапе, репортёры, аналитики, и иногда даже наши клиенты упорно называли нас «ИИ-компанией». Какое-то время мы открещивались от ярлыка «ИИ», понимая, что наша платформа в обозримом будущем не будет наступать на пятки системе IBM Watson. Но в итоге мы сдались, и решили просто не сопротивляться шумихе. Рынок хотел, чтобы мы были ИИ-компанией, и мы, посмеявшись, решили так и называться.