Backend Engineer
Chief Technical Officer — представитель топ-менеджмента компании (помимо английской аббревиатуры, можно встретить название «технический директор»), который определяет технологическую стратегию компании и отвечает за внедрение новых технологий — все ради достижения финансовых и стратегических целей бизнеса.
Привет, Хабр! Меня зовут Владимир, я работаю программистом в компании Quadcode. Вот уже почти полтора десятилетия я при помощи доброго десятка языков программирования разрабатываю приложения - от простых, вроде маленького плагина для Emacs, до сложных распределенных систем. Последние 4 года своей жизни я посвятил компании Quadcode, где занимаюсь разработкой транспортной подсистемы. Лет пять назад я вплотную столкнулся с адептами TDD (test-driven development) и это произвело на меня настолько сильное впечатление и оставило так много эмоций, что я написал “для своих” критический разбор наиболее часто встречаемых мною тезисов об этой технике (я бы даже сказал - учении). До сих пор мое мнение о TDD не изменилось, так что хотел бы описать его под катом и предлагаю обсудить вместе спорные моменты в комментариях.
Программисты пишут код (удивил, да?) Если это пет-проект, то вы вольны делать со своим кодом все, что хотите. Но когда над одним проектом работает несколько человек или даже целая команда, рано или поздно встаёт вопрос о необходимости код-ревью. Кому отдать на ревью? Как ускорить этот процесс? Как равномерно распределять реквесты по ревьюерам? Вопросов много, а ответы не так очевидны. В этой статье расскажу, с какой проблемой мы столкнулись в команде автотестирования в Wrike, как у нас устроен процесс ревью и зачем нам понадобился самописный сервис.
Что такое эта ваша многопоточность и как с ней жить? Попробуем разобраться что за зверь pthread, зачем нужен RunLoop, какие примитивы синхронизации доступны в iOS разработке, а так же, какие проблемы за собой влечет многопоточность.
Прим. перев.: системный архитектор Avery Pennarun, создавший VPN-решение Tailscale на базе WireGuard, размышляет об отличиях монолитов с модулями от микросервисов. Он рассказывает об эволюции подхода к модульности вообще и о том, почему изоляция до сих пор далека от совершенства, а также делится своим мнением о том, когда проводить границы между сервисами рационально.
В последнее время меня часто спрашивают, в каких случаях переход на микросервисы — хорошая затея. В статье «Systems design explains the world» я размышляю о таких типичных проблемах, как эффект второй системы, дилемма инноваторов и других. Может ли проектирование систем дать ответ на вопрос о микросервисах? Да, хотя ответы могут вам не понравиться.
Меня зовут Марина Перескокова. Я проработала в Яндексе 10 лет, и из стажёра-разработчика выросла до руководителя службы разработки фронтенда. За это время получилось поработать над JS API Яндекс.Карт, поруководить фронтендом сервиса yandex.ru/maps и покодить движок для векторной карты на WebGL. По итогам моего тимлидства я написала книгу.
В какой-то момент я поняла, что у ребят все хорошо и без меня, и попросила новых задач. Так я стала совмещать роль руководителя службы разработки с ролью менеджера продукта и занялась развитием дизайна подложки Яндекс.Карт. Это был очень интересный опыт, и с точки зрения работы над продуктом, и с точки зрения коммуникаций — для воплощения в жизнь некоторых задач приходилось состыковывать до пяти разных команд в разных отделах.
Я в двух статьях расскажу про свой опыт перехода из тимлида разработки в продакт-менеджера. Пройдём по всем аспектам: какие преимущества есть у разработчика, с какими сложностями вы можете столкнуться, как их преодолеть, что плохого и хорошего случится в пути, и главное: как понять, что это ваше.
Не так давно Microsoft выкатил в публичный доступ ИИ Copilot. Он обучен на базе GitHub и помогает разработчикам дополнять код в зависимости от контекста. С нуля пока ничего не создает, но некоторые функции может написать целиком без участия программиста. И возникает вопрос — а не близок ли тот день, когда искусственный интеллект полностью заменит разработчиков, и, например, заставит их переквалифицироваться в бизнес-аналитиков.
Мы побеседовали со специалистами по ИИ и Data Science, чтобы оценить реальные перспективы искусственного интеллекта. А еще спросили разработчиков, героев наших прошлых статей, что они думают об ИИ и не боятся ли потерять работу из-за технического прогресса. Приходите в комментарии и тоже делитесь своим мнением.
Эта статья является переводом материала «Immutable architecture».
В этом посте автор оригинала хотел бы показать общий подход к внедрению иммутабельности в кодовую базу на архитектурном уровне.
Прежде всего, термин «Иммутабельность», применяемый к структуре данных, такой как класс, означает, что объекты этого класса не могут изменяться в течение их жизненного цикла. Существует несколько типов иммутабельности со своими нюансами, но это не являются для нас существенным. По большей части мы можем сказать, что класс является либо изменяемым, что означает, что его экземпляры могут изменяться тем или иным образом, либо иммутабельным (неизменяемым), что означает, что как только мы создадим экземпляр этого класса, мы не сможем изменить его позже.
Всём привет! Меня зовут Дядиченко Григорий, и я CTO Foxsys. В разработке я порядка 8 лет, а занимаюсь игровой или AR/VR разработкой последние лет 6. Сразу скажу, что в данной статье нет простого ответа “этот игровой движок лучше”, и она не претендует на объективность. Я лишь расскажу мнение с точки зрения технического директора и человека за плечами которого порядка 40 коммерческих проектов. Если вам интересно — добро пожаловать под кат.
Спор «фуллстек против узкой специализации» вечный. Но одно дело — спорить в комментах, а совсем другое — создать собственную компанию и проверить экстремальный подход на практике. Антон Кекс пошел по этому пути: стал сооснователем компании Codeborne, где разработкой занимаются исключительно «фуллстек-крафтсмены» и практикуется экстремальное программирование. И по его словам, там командами из 2-4 человек получается сделать то, на что другим требуется человек 50.
Он подробно рассказал об этом на нашей конференции JPoint. Обычно на наших мероприятиях не услышишь слово «agile», потому что о методологиях много пустословия, а мы любим конкретику, код и хардкор. Но поскольку Антон не диванный теоретик, а обладатель большого нестандартного опыта, это как раз хардкор и ценная информация.
Можно не соглашаться с его позицией, но как минимум ознакомиться с ней полезно. И хотя доклад сделан еще пару лет назад, в 2021-м он продолжает собирать просмотры, поэтому мы решили сделать для Хабра текстовую версию. Под катом — и видеозапись, и текстовая расшифровка. Дальше повествование ведется от лица Антона.
Иллюстрация из мультфильма «Про бегемота, который боялся прививок», Союзмультфильм, 1966. Режиссёр Л. Амальрик, Художники-постановщики: Н. Привалова и Т. Сазонова.
Побочные явления - тема очень острая и сложная, но говорить об этом необходимо, чтобы информационный вакуум не заполнялся фейками. Любая вакцинация несет небольшие риски нежелательных реакций, но опыт миллионов вакцинированных во всем мире показывает, что вакцины от covid-2019 переносятся большинством людей без негативных последствий для здоровья. Серьезные побочные реакции встречаются с частотой на несколько сотен тысяч и миллионов вакцинированных.
Риски вакцинации несоизмеримы с рисками смерти и тяжелых осложнений covid-2019. Официально в России на конец июля зарегистрировано 154 тыс смертей на 6,140 млн заболевших, это соответствует летальности 2,5% (цифры по избыточной смертности намного печальнее). Эпидемия не остановится пока не сформируется коллективный иммунитет, но у нас есть выбор между минимальными рисками, связанными с вакцинацией, и высокими рисками covid-2019.
Заметка посвящена описанию возможного механизма отбора наиболее перспективных с точки зрения склонности к оплате внутриигровых услуг пользователей и его критике. Цель: рассмотреть функционирование, положительные и отрицательные стороны упомянутого механизма. Область применения: разработка игр, монетизация, работа с интересами и пользователями. Требуемый уровень: базовое понимание компьютерных и мобильных игр с точки зрения пользователя.
Все указания на названия, торговые марки и проч. не являются рекламой. Статья основана на пользовательском опыте и академических и практических знаниях.
“Жил-был руководитель. Он самостоятельно поднял на ноги компанию и гордился этим. Как и все, на старте он начинал сам, но потом, в процессе масштабирования к нему начали приходить сотрудники. Компания продолжала быстро расти и ему приходилось работать больше и нанимать еще больше людей в помощь.
Сотрудники приходили разные, но большинство были обычными среднестатистическими людьми, которые не отличались повышенной ответственностью и трудолюбием. В общем, простые нормальные люди. Иногда руководителю везло и ему попадались звездочки, которые работали по 12 часов и были более профессиональны и квалифицированы. На таких сотрудников наш руководитель не стеснялся грузить основную часть задач и подключать их во все и вся компании.
Прошло еще немного времени, компания продолжала расти и масштабироваться. Появлялись все новые и новые возможности и проекты, но несмотря на уже солидный штат часто приходилось от них отказываться из-за неуспеваемости. По тем же проектам, которые все таки брались в работу, также было не все гладко: срывались сроки, хромало качество, клиенты жаловались…
Руководитель понимал, что нужно что-то менять, и что без солидной профессиональной поддержки ему не обойтись. Он решил нанять ТОПов на ключевые позиции, которые бы закрыли на себе большую часть проблемных вопросов.
Просчитав бюджет, он понял, что ему вполне хватит денег и решил сразу закрыть все позиции (а таких он определил пять).
Он запустил процесс поиска, разместил вакансии, рекрутеры начали искать людей. Начался поток собеседований, которые еще больше выбили руководителя из сил: ибо теперь, чтобы успеть и работу сделать, и собеседования провести, ему нужно было еще больше работать.
С горем пополам он закрыл одну позицию, потом вторую. Но закрыл как? Закрыл имеется в виду нашел человека и согласовал дату выхода.
Итак, найденные специалисты вышли. Руководитель провел им вводную экскурсию и со словами: "Ну, за работу" - отпустил их в свободное плавание. А что? "Ведь они профи и сами знают, что нужно делать, а моя задача им не мешать" - считал руководитель.
Прошли недели, а руководителю казалось, что становится еще хуже. Он был удивлен, что специалисты, которые имели большущий опыт, которые собаку съели в своем деле, так медленно и хило раскачиваются. Получилось, что тратить наш руководитель стал больше, работать стал больше, а выгоды никакой не получил. А он то ожидал, что они придут и сходу его разгрузят…
Прошло еще немного времени и в компании начали происходить разные странности. Специалисты, которых он нанял, профессионально делали то, что не нужно: первый начал трансформировать структуру, второй запустил неприоритетный проект, на третьего вообще поступали жалобы, что он слишком жесткий… . Руководитель рвал на себе волосы и не понимал, как так мог ошибиться в людях. Теперь ему, пришлось идти на крайние меры и увольнять их. Но что делать с последствиями от их деятельности и их ухода?..."
Интересное в этом выпуске
Выпущены версии Go 1.17rc1, 1.16.6 и 1.15.14, GitHub представил инструмент проверки безопасности GO, Перехватываем и изменяем сетевые пакеты на примере игры, Рекомендательная система
Приятного чтения!
Ревью кода это довольно обыденный процесс. Хотя и не многие могут объяснить, зачем это нужно команде — ревью будто без вопросов необходимо для мифического "хорошего кода". В целом сообразить пару причин, зачем же делать просматривать код коллег довольно просто, но такие причины далеко не всегда имеют весомое подтверждение. И далеко не всегда ревью достигает предполагаемых целей из-за недостаточного качества ревью и вовлечения команды.
Я расскажу про причину зачем вам лично может быть полезно ревью кода сокомандников.
Интернет завален статьями «как войти в IT и начать писать код», но куда реже говорят о том, как перестать его писать. Что делать, если больше не хочется весь день смотреть в IDE, но и в тимлиды не тянет? Конечно, можно освоить свиноводство, но есть ли сферы, где пригодится уже полученный опыт? Куда можно свернуть «в сторону» от разработки, и какие скиллы для этого понадобятся?
Это похоже на прокачку веток развития персонажа в RPG-игре. Ставишь на ловкость или качаешь силу — получаешь разный результат. Мы выбрали четыре направления, в которых можно качать своего персонажа, и задали вопросы людям, которые уже прошли этими путями:
Датские инженеры представили алгоритм, который уже используют крупные ИТ-компании и облачники. Рассказываем, как он устроен и обсуждаем перспективы.
