Привет, Хабр!

Сегодня мы поговорим о двух концепциях — Event Sourcing и CQRS, и их реализации на языке Go. Go предоставляет хорошие возможности для реализации этих паттернов благодаря своей производительности, простоте и поддержке конкурентности «из коробки».

Если составлять топ самых крутых изобретений человечества, то второе место сразу после кофеварки наверняка займёт opensource – разработка проектов с открытым исходным кодом, которая помогла родиться поистине огромному числу полезных и гениальных продуктов. Причём опенсорс важен не только для сообщества программистов в целом, но и для каждого конкретного разработчика: участвуя в создании программ с открытым кодом, они могут неплохо развить свои скиллы, обрести новых друзей со сходными интересами и, конечно же, потешить своё самолюбие. Признайтесь, вам хотелось бы, чтобы вашей библиотекой пользовался весь мир?

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

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

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

Разработчики приложений с микросервисной архитектурой обращаются к Golang не только как к основному языку, но и как к вспомогательному — в дополнение к другим, более сложным. А мы решили обратиться к спикеру курса «Golang-разработчик» Виталию Лихачеву, Senior Software Engineer в Avito, чтобы он нам рассказал, почему лично он выбрал бы Go. 

Привет! Меня зовут Бенуа, я работаю разработчиком программного обеспечения последние 8 лет. В своей предыдущей компании я проработал 7,5 лет, а в начале 2022 года перешел в новую.

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

То, чем я здесь делюсь, может быть полезно любому Junior или Middle разработчику, который хочет совершенствоваться и продвигаться к уровню Senior и выше. Советы в этой статье по большей части касаются так называемых мягких навыков, по техническим навыкам я пройдусь отдельно во второй части.

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

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

Привет! Меня зовут Кирилл Комиссаров, я пришел на позицию лида примерно полгода назад. Срок небольшой, но за это время многое понял о том, почему доверие в команде так важно. 

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

Позиция тимлида вообще предполагает relationship management, который может быть направлен как и на команду, так и наверх, в сторону стейкхолдеров. Но в этой статье я хочу поговорить именно про связку TL + Dev Team. Руководителю важно выстроить и поддерживать доверительные отношения с сотрудниками. Это поможет эффективно управлять командой и добиваться слаженной и продуктивной работы.

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

Я говорил с коллегами, читал статьи по теме, прослушал курс Стратоплана и в итоге собрал несколько идей и правил, которые сам применяю на практике, чтобы наладить стабильные процессы в команде и добиться доверия сотрудников.

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

Сейчас мне 41 год, больше 15 лет я в бизнесе. Год назад я поступил в магистратуру на мехатроника-робототехника и стал изучать Python и машинное зрение. Как я пришёл к этой идее — не самое интересное (спойлер: через техническое хобби — спортивных дронов). А вот что из этого вышло и как новые знания помогают мне в бизнесе и могут помочь предпринимателям в целом — я подробно расскажу в этой статье.

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

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

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

Я написал своё первое одностраничное веб-приложение на Javascript в 2005 году, сразу после того, как узнал о XMLHttpRequest и до появления серьёзных фреймворков. Я оставил профессиональную веб-разработку примерно в 2009 году (а начал её в 1997 году с WebObjects), а последний десяток лет своей карьеры занимался мобильными.

Сегодня я смотрю на мир веб-разработки, и меня поражает его безумие. Существует так много фреймворков для веба, и каждый день появляются новые. Для создания веб-приложения (в отличие от веб-сайта, например, моего сайта про искусство, который сгенерирован статически и содержит лишь немного Javascript), часто требуются кучи инструментов и технологий, часто меняющихся с большой частотой и содержащих бесконечные объёмы других технологий, о существовании которых мы и не подозреваем (о, смотрите-ка, в папке пакета две тысячи файлов).

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

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

Сегодня ровно 20 лет, как я начал программировать профессионально. За эти годы я:

• Получил одобрение на петицию по грин‑карте за выдающиеся способности в науке.
• Стал Google Developer Expert.
• Стал IEEE Senior Member.
• Был операционным директором в компании со 100 сотрудниками.
• Написал код, который скачали 135 миллионов раз.
• Выступал перед аудиторией в 2000 человек, дважды.
• Стал самым честным человеком в России по версии НТВ.

Но упустил я гораздо больше и делал всё это слишком долго. Думаю, этот путь можно было бы пройти «на скорость» лет за 5 с теми подходами, принципами и приоритетами, которым я научился. Если вы только начинаете свой путь, этот текст может сэкономить вам 15 лет жизни.

Привет, Хабр!

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

Go с помощью своей простоты и поддержкой конкурентности становится хорошим кандидатом для работы с WebSocket.

Привет, Хабр!

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

Go благодаря своей простоте, производительности и, что наиболее важно, поддержке конкурентности на уровне языка, становится идеальным выбором для создания fault-tolerant систем.

Что мне больше всего нравится в gamedev, так это что большая часть игр и каждый первый кастомный игровой движок бросают вызов устоявшимися стереотипам разработки. Иначе зачем начинать разработку такого сложного и комплексного софта, когда десятки похожих софтин есть вокруг. Конечно такие монстры как Unreal и Unity и десяток монстриков калибром поменьше существенно упростили разработку во многих отношениях, привлекли тысячи разработчиков к созданию множества великолепных игр с использованием готовых технологий, освободив их от ямы отчаяния пустого уровня. Но также не оставляет мысль, что еще больше игр они похоронили. Невзирая на весь функционал и мощь U/U люди часто застревают в рамках, о которых они даже не подозревали. На протяжении многих лет наблюдаю как оригинальный контент в большинстве случаев убивается ассетсторами, если там есть что-то близкое или похожее к нужному объекту, функционалу и виду. Не поймите мои слова неправильно, я обеими руками за магазины ассетов и любых других ресурсов, скриптов и технологий, но беря что-то в магазине за доллар, вы уже с большой вероятностью не сделаете свое. Или сделаете конечно, но позже, но до этого "позже" еще надо дожить, а пока что у вас будет всё как у всех: одинаковые паттерны, одинаковые текстуры, одинаковое поведение, одинаковые модели... и одинаковые игры? Что тогда остается своего - уникальные механики и впечатления. В другом случае не было бы игры, вот только проблема, что сначала люди видят картинку. Хорошо если игрок через полчаса-час доберется до уникальных механик, одинаковая картинка вызывает в памяти игры в которые вы уже играли, а уникальная механика так никогда может быть и не увидена в игре.

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

Мы с HR-платформой Beehive опросили 2000 IT-специалистов, чтобы понять, как обстоят дела с выгоранием в IT-сфере, и провести качественное измерение этой как будто уже вечной проблемы. Все ответы под катом.

За последние пару десятилетий с ростом объёма данных на рынке СУБД сложился интересный ландшафт. Появились новые СУБД, при этом старые продолжали развиваться — и сориентироваться среди них становилось всё сложнее. 

В этой статье предлагаем рассмотреть эволюцию разных СУБД и сравнить их между собой. Поможет нам в этом Олег Бондарь, директор по продукту в Yandex Cloud, который отвечает за развитие YDB — это транзакционная реляционная база данных с открытым исходным кодом. Статья написана по материалам его доклада на Saint Highload++.

Идея этой статьи родилась из обсуждения в чате канала «UI фэйл» (https://t.me/uifail), который ведёт мой коллега и друг Денис Пушкарь. В процессе сборки материала я обращался к коллегам из других команд и направлений (в том числе разработки, тестирования и аналитики), чтобы подтвердить или опровергнуть свои умозаключения, так как тема весьма обширная, а пишет статью по ней человек из сферы дизайна.

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

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

Ниже по тексту я распишу трудности, с которыми сталкивается специалист в IT на всём протяжении своего роста, и о которых очень мало говорят.