Техлид
Я написал эту статью для себя, но подумал, что она будет полезна и начинающим айтишникам, и тем, кому необходимо освежить знания или быстро вспомнить основные вещи, не открывая полное руководство.
Ещё раз подчеркну, статья задумывалась как базовая памятка и помощь для начинающих, а никак не исчерпывающая документация. Многое я опускаю ввиду избыточности или неактульности, по крайней мере в моей работе.
Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.
В этой статье я постарался кратко и последовательно изложить основные моменты, о которых полезно помнить при использовании RabbitMQ, если важны стабильность обмена и сохранность данных.
В первую очередь материал рассчитан на разработчиков, которым ещё не приходилось погружаться в тонкости работы с RabbitMQ или использовать его вообще. Более опытным читателям статья может пригодиться в качестве компактной и упорядоченной выжимки из уже знакомых статей, вебинаров и многочисленных страниц документации.
Недавно мы публиковали на Хабре целую серию статей о карьере в IT. Теперь собрали ключевые советы и полезные ссылки из этих материалов. Статью можно использовать в качестве краткого помощника для тех, кто решил сменить работу.
То, что ChatGPT может автоматически генерировать что-то, что хотя бы на первый взгляд похоже на написанный человеком текст, удивительно и неожиданно. Но как он это делает? И почему это работает? Цель этой статьи - дать приблизительное описание того, что происходит внутри ChatGPT, а затем исследовать, почему он может так хорошо справляться с созданием более-менее осмысленного текста. С самого начала я должен сказать, что собираюсь сосредоточиться на общей картине происходящего, и хотя я упомяну некоторые инженерные детали, но не буду глубоко в них вникать. (Примеры в статье применимы как к другим современным "большим языковым моделям" (LLM), так и к ChatGPT).
Привет, хабровчане! Многие из нас дорастают до момента, когда приходится проводить собеседования для поиска нового сотрудника в команду или стороннего исполнителя. Вне зависимости от направления (бэкенд, фронтенд, тестирование, мобильная разработка) интервью строится на основе ограниченного набора инструментов: скринингов, тестовых заданий, лайвкодинга и теоретических секций. В статье расскажу про типовые ошибки интервьюеров и лучшие практики, поделюсь своим планом собеседования и подробно остановлюсь на одном из инструментов — лайвкодинге.
Перед тем, как начать, буквально пару слов о себе. Меня зовут Роман Лунев, я руковожу отделом бэкенд-разработки в команде развития суперприложения ВКонтакте. Разработкой занимаюсь более 10 лет, а собеседования провожу уже порядка 6–7 лет. За это время я много раз успешно заваливал, а потом, с опытом, и успешно проводил собеседования как интервьюер. А ещё насмотрелся на косяки коллег, потому что время от времени погружал в этот процесс интервьюеров-новичков. А это даёт очень много пищи для размышлений. Расскажу про свой план собеседования.
Веб-сайты уже давно перестали напоминать простые листы с текстовой информацией. Сейчас это полнофункциональные приложения, порой с очень сложной и тяжелой логикой. А чем больше логики и чем сложнее она становится, тем сильнее сайт начинает замедляться, что, естественно, не нравится пользователям. Сейчас это решают разными способами, например с помощью ленивой подгрузки, а более рисковые пробуют применять микрофронты или виджетные системы. Однако есть еще один вектор, на который пока никто не обращает внимания: использование многопоточности в браузере.
Практически во всех областях IT-разработки весь мир перешел на использование многопоточности: мобильные приложения, бэкенд, прикладное программирование. И даже процессоры развиваются в сторону увеличения количества ядер. Но на фронте многопоточность используют нечасто, и эта тема до сих пор почему-то не очень популярна, особенно в ру-сообществе.
Сегодня я постараюсь это исправить, открыв для вас фантастический мир многопоточности в браузере.
Peace, Хабр!
Честно говоря, я долго думал, как бы потактичнее начать. Но ничего не придумал. Поэтому напишу прямо: я хочу, чтоб моя жена и ребенок ни в чем не нуждались. И у меня была уверенность, что могу им дать все, что потребуется: от любви до игрушечной железной дороги.
Сегодня пошел 8-ой день, как от этой уверенности почти ничего не осталось.
Этот пост не про деньги (хоть он и почти весь про финансы). Этот пост про то, как увеличить свои шансы и шансы своих близких жить в достатке в условиях экономической изоляции и деградации гражданских институтов.
Привет, Хабр!
В моей IT-карьере время от времени судьба распоряжалась так, что мне выпадало возглавить новые команды разработки. Причем это были уже устоявшиеся сформированные коллективы, для которых я был новым непонятным персонажем, входившим в их уютный монастырь со своим уставом. В этой статье я хотел бы обобщить и сформулировать шаги, которые я предпринимал для «вливания» в коллектив и построения «доверительной» рабочей атмосферы.
Эта статья может быть интересна ребятам, которые переходят в новые компании на руководящие должности техлидов и тимлидов, либо разработчикам, которым выпало неожиданно возглавить не их «родные» команды.
Итак, рассмотрим ситуацию, когда в команду разработки (или в командЫ разработки) приходит новый руководитель, о котором самим участникам команды ничего не известно. И этот руководитель — вы.
Event storming — метод, который смещает акцент у событий с технического на организационный и бизнес уровни и помогает создать устойчивую модульную систему. Он нередко используется в контексте моделирования микросервисов. Но как применить его на практике?
При создании системы на микросервисах можно легко получить распределенный монолит. Event Storming не уберегает от этого на 100 %, но позволяет существенно снизить риск этого события. О том, как именно этого добиться, рассказал в своем докладе на конференции TechLead Conf 2020 практикующий консультант по архитектуре, процессам разработки и продуктовым практикам Сергей Баранов.
Прошло уже почти 3 года с тех пор, как я впервые воспользовался чистой архитектурой на практике. С тех пор я побывал на многочисленных конференциях, где выступал с докладами на эту тему (вот, например, доклад Clean Architecture in Python с конференции PyGotham 2018). Кроме того, я написал статью о чистой архитектуре на Python, которая попала в рассылку RealPython.com … но сейчас заканчивается 2021 год, и мы ушли далеко вперед. Давайте рассмотрим, как развился Python, изучим разные крутые библиотеки, благодаря которым реализовывать чистую архитектуру на Python сегодня стало гораздо проще.
Сначала вспомним о том, зачем она нужна.
Чего мне всегда не хватало, так это аналога JSFiddle для SQLite. Онлайн-песочницы, в которой можно быстро проверить SQL-запрос и поделиться с другими.
Вот чего хотелось:
— Возможность загрузить готовую базу, а не писать SQL для создания таблиц.
— Подключать как локальные базы, так и удаленные (по url).
— Сохранять базу и запросы в облаке.
— Бесплатно и без регистрации.
— Свежайшая версия SQLite.
— Минимализм.
Эта статья подходит для тимлидов и их подопечных, а также для всех, кто оценивает проекты и задачи. Я расскажу, как и почему мы делаем ошибки из-за когнитивных искажений. Попадаем в них мы почти все, просто потому что мы живые люди. И на примере одного дня из жизни тимлида я хочу показать, в какие искажения чаще всего влетают в IT, и — самое полезное — как из них можно выходить.
Замечу, что искать когнитивные искажения стоит, в первую очередь, у себя, а не у коллег. И что рассказывать про искажения намного проще, чем не влетать в их на практике, однако, если этому научиться, то в перспективе это изрядно окупается, потому что экономит и время, и деньги, помогая и нам, и команде.
Всем привет! Сегодня в гостях у нас Олег Мельник — Technical Lead в компании Proxify, а также преподаватель в OTUS.
Поговорили с Олегом про такую роль у разработчиков как техлид.
Python предоставляет программисту огромное пространство свободы. Увы, обычно это довольно дорогая в плане производительности свобода, зато при правильном применении иногда она позволяет творить сущую магию. Но сегодня мы поговорим не о таких вот «богоугодных» применениях свободы, а о том, что никогда не стоит использовать в прикладном программировании — о модификациях кода на уровне AST.
