Пользователь
Пока все кому не лень пишут статьи о том, как войти в айти, некоторые из нас нет-нет, да задумываются, а не выйти ли оттуда. Ночные релизы, бесконечные переработки, легаси код, невнятные баги, грубые разговоры в курилках и в коридорах, постоянные требования от менее технически подкованных коллег, иногда целые блоки кода, а то и сборки, отправленные в корзину… Выгорание? Жажда новой жизни? А вдруг там, за дверью серверной или опенспейса R&D, всё по-другому?
Всем привет! Возможно уже совсем скоро разные новостные и IT-ресурсы будут подчищать информацию о способах обхода блокировок. А пока этого не случилось, запасаемся полезными гайдами и разворачиваем свои собственные VPN с защищенными от блокировок протоколами. Расскажу как это сделать, как изменилась Amnezia и как мы защитили WireGuard от блокировок.
Многие игроки считают, что разработка — это интересный и увлекательный процесс (о, святая наивность!). Это, конечно, так, но, к сожалению, в этой сфере вся романтика заканчивается, когда начинаются проблемы. Одной из таких проблем и является «кранч», или работа на износ. Карьера в области искусственного интеллекта или Data Science не застрахует от переработок полностью, но в последнее время компании понимают, что культура кранчей не приводит к хорошим результатам. В данном посте попробуем разобраться с этим неприятным явлением, которое заставляет разработчиков сходить с ума.
Старайтесь изо всех сил, чтобы произвести впечатление на своего начальника.
Думайте, что команда Вас уважает за Вашу работу, когда команда токсична.
Создайте иллюзию, что продвигаетесь вперед и Вас замечают.
Переработки ничего Вам не дадут. Ваша компания будет благодарна за бесплатную работу. Ваш начальник может быть не против воспользоваться Вашей трудовой этикой. Ваша команда будет возмущена новыми ожиданиями и оценками, которые Вы устанавливаете.
И Вы сгорите, не продвинувшись вперед.
Пару месяцев назад Steam выложил в Steamworks инструмент для разработчиков, позволяющий отправлять игры на сертификацию: Steam тестирует и проверяет игру, а затем решает, совместима ли она с Steam Deck. Так как я уже реализовал в своей игре поддержку геймпадов, то сразу приступил к делу. Мне понадобилось два месяца переписок со Steam, чтобы он наконец верифицировал полную совместимость игры со Steam Deck. Я не нашёл особо много информации об этом процессе, поэтому захотел поделиться своим опытом, чтобы другим разработчикам не приходилось совершать те же ошибки.
Примечание: у меня нет Deck и я ни разу им не пользовался. Разработка игры целиком зависела от помощи моего фаната и простоты разработки под сам Steam Deck.
Всем привет! Я Тёма Логинов, за 4 года работы в digital я неоднократно искал работу, нанимал людей и помогал это делать другим.
Многие компании оформляют вакансии по-странному: предлагают работу за три рубля или вешают на одного сотрудника работу целого отдела. Рассказываю, как распознать такие вакансии, чтобы уберечь себя от работы на [ч]удаков.
На собеседованиях на позицию middle/senior разработчика часто задают вопросы по распределенным транзакциям в микросервисной архитектуре.
Мой коллега однажды посоветовал отличную статью со сравнением основных паттернов для решения проблем распределённых транзакций.
Я проработал статью и подготовил конспект простыми словами, местами дополнил информацией из других источников и полезными ссылками.
Перед тем как начать, делюсь ссылкой на мой блог в телеграм, где я раньше всего публикую материалы по java разработке и личной эффективности.
В свободное время я восстанавливаю старенькую, но довольно известную игру Pharaoh. Это ситибилдер, выпущенный в прошлом веке и разработанный Impressions Games. Технология рендеринга в этой игре была значительным достижением для своего времени и способствовала созданию впечатляющей атмосферы Древнего Египта, которая погружает игрока в проработанное окружение, удивляет вниманием к мелким деталям и передает богатство и разнообразие древнеегипетских пейзажей. В этой статье я опишу алгоритм отрисовки города, зданий, объектов, анимации и формат карты оригинальной игры.
Около двух лет назад вышла небольшая статья Kafka Streams — непростая жизнь в production, в которой я описывал сложности, с которыми наша команда столкнулась при попытке решить задачи проекта с помощью kafka-streams. Эксперимент вышел неудачным, и мы в итоге совсем отказались от этой технологии. Вместо нее решили попробовать Clickhouse (CH), и сейчас уже можно сказать, что эта база нам очень хорошо подошла и отлично решает почти все задачи, которые нам ставит бизнес. В этой статье я расскажу об особенностях использования CH.
С реляционными базами данных я знаком очень давно, с конца 90-х. Мои первые шаги в мире компьютеров и программирования связанны именно с ними. Реляционным БД было отведено особое место в моей образовательной программе и стажировке на инженера-программиста. Они преследовали меня на протяжении всей моей карьеры. Я буквально провалился на самое дно кроличьей норы реляционных систем управления базами данных (РСУБД) – и до сих пор люблю их.
За годы работы я испробовал практически все РСУБД, а их попадалось мне немало: MySQL, Postgres, Oracle, Microsoft SQL Server, DBase, Access, SQLite, DB2, MariaDB, AWS RDS, Azure SQL, Google Cloud SQL. Нельзя любить РСУБД, если не любишь SQL, а это отдельная вселенная. И не все SQL одинаковы. Есть MySQL со своим собственным жаргоном, есть T-SQL от Microsoft и всемирно известный PL/SQL от Oracle. Наверное, не стоит упоминать, что все они несовместимы друг с другом.
В последние полгода появилась четкая тенденция: крупные корпорации загоняют сотрудников обратно в офис. Они обязуют 60% рабочего времени проводить в офисе, что примерно равно трем дням в неделю.
Приводятся разные доводы: кто-то говорит, что в офисе лучше строится доверие, другие считают, что сотрудники в продуктивнее работают вне дома. Давайте разбираться!
Сам работаю программистом в Амазоне уже больше двух лет. Начинал в команде в Ванкувере, Канада. Мне не понравилось и я переехал в Испанию, поменяв команду.
В этой статье, я хотел бы обратить внимание на проблемы во взаимодействии, коммуникации между участниками команды разработки. Определить причины, предложить решение. Также в конце статьи вы можете найти список технических вопросов, ответы на которые помогут улучшить коммуникацию между отделами (арт и тех) с самого старта проекта.
В Go 1.20 сделали возможность сбилдить приложение с флагом cover
go build -coverпосле чего, если запустить такое приложение, то будет собираться статистика, показывающая, какие части кода были выполнены, а какие нет, и складываться в папочку, указанную в переменной окружения.
Это, конечно, было сделано для интеграционных тестов, когда приложение запускается целиком в каких-то сценариях (а не через go test), но, вероятно, это можно попробовать использовать и по-другому:
запустить такой бинарник прямо на проде, подержать какое-то время и посмотреть, какие участки кода в реальности никогда не запускаются.
Так можно найти недовыпиленный легаси-код, старые эндпоинты API, которые давно никому не нужны, малозначимые проверки if err != nil и прочее. Как минимум, на это интересно посмотреть, можно найти что-нибудь удивительное.
Disclaimer: разумеется, сбор статистики создает какой-то оверхед, поэтому подойдёт точно не всем. Как вариант, можно пустить туда небольшую часть трафика.
Исходный код программы надо визуализировать — отобразить в виде схем для лучшего понимания, изучения, осмысления, создания документации и др.
Рисовать схемы вручную никто хочет — надо создавать их полностью автоматически, автодокументацией.
Предлагаю вниманию несколько инструментов для визуализации кода.
❓Как проектировать системы, которые будут толерантными для различного вида отказов и ошибок?
Что такое отказоустойчивость и стабильность?
Под отказоустойчивостью будем понимать свойство системы, которое позволяет максимально сохранять работоспособность при отказе отдельных конкретных компонентов системы либо связанных систем и восстанавливать работоспособность системы при восстановлении отказавших компонентов или связанных систем. Давайте рассмотрим подробнее эти 2 момента:
1. Деградация работоспособности системы должна быть прямо пропорциональна "величине" отказа. То есть, если упал сервис, отвечающий за некую некритичную функциональность — вся система не должна при этом падать. Да, небольшой кусочек не работает, но это не влияет на стабильность остальной части функционала.
2. Стабильность системы предполагает самостоятельного восстановления работоспособности после сбоя как компонентов системы, так и всей системы в целом. К примеру, если пропадала сеть на некоторое время — то у стабильных систем после восстановления подключения все компоненты продолжат работать и данные вернутся в консистентное состояние без ручного вмешательства со стороны команды эксплуатации.