В 2021 году на рынке фронтенд-технологий лидируют React, Angular и, с некоторым отставанием, Vue. В нашей компании для унификации подбора разработчиков сделан упор на React, но ряд крупных систем разрабатываются с помощью современных версий Angular. В связи с конкуренцией этих технологий возникло желание изучить каждую из них и составить собственное мнение о применимости этих инструментов.
2020-й год, март, нерабочие дни... Кто бы мог подумать, что формат работы настолько поменяется? «Как тебе удалёнка?» — один из самых частых вопросов, который звучит с тех пор.
Скажи мне, как ты относишься к переработкам и я скажу, кто ты...
Задаваться вопросом о том, как вообще происходит так, что люди перерабатывают, я начал ещё в раннем детстве. Матушка моя периодически задерживалась на службе, из-за чего я допоздна сидел с воспитателями в садике, осознавая, что на вечерние мультики я уже не попадаю. Так я впервые познакомился с неудобствами, которые несут переработки, даже если ты сам имеешь отношение к работе чуть менее, чем никакое.
Не все ML-проекты начинаются с четкого формулирования результата, который мы хотим получить на выходе. С какого-то момента задача обретает стандартную для машинного обучения постановку: появляются данные и требования к модели. Однако такой постановке может предшествовать долгий и неочевидный процесс.
Если вы хоть раз смотрели детектив, то понимаете, как выглядит первичный этап в ML-проекте: проверяется множество гипотез, много времени уходит на сбор данных и погружение в процессы, планы часто меняются по ходу работы, все постоянно торопят. Несмотря на неопределенность, именно этот этап позволяет раскрыть весь потенциал внедрения машинного обучения, а значит важен как для бизнеса, так и для data scientist'ов.
Меня зовут Настя, я DS Team Lead в компании Домклик. В мае этого года мы запускали data science в команде «Речевые сервисы». За полгода реализовали несколько успешных проектов, об одном из них пойдет речь.
Уже давным-давно я работал в одной крупной компании в должности C++-разработчика и столкнулся с одной очень странной ошибкой. Я написал примерно такой класс:
class Foo {
static void* operator new() {
return ...;
};
};
И увидел огромный stack-trace ошибок о недопустимом вызове оператора в этом контекста (на тот момент я использовал MS Visual Studio 2013 и встроенный в него MSVC-компилятор). Я искал проблему часа два, и помогло мне только просматривание готовой единицы трансляции. Как вы могли догадаться, проблема была связана с препроцессором, но обо всём по порядку.
С помощью микросервисной архитектуры можно построить масштабируемое и гибкое приложение. Однако, если команда бессистемно использует этот подход в своей работе, то скоро столкнется с разочарованием и неконтролируемой сложностью. Избежать этого поможет DDD (Domain-Driven Design, предметно ориентированное проектирование). Не так давно я ничего не знал про этот подход, но сейчас я постоянно натыкаюсь на эту тему.
Представляю вам перевод статьи "How to Implement Domain-Driven Design (DDD) in Golang". Повествование буду вести от лица автора, иногда прерывая собственными мыслями в таком же формате, как и это отступление. Приятного чтения.
Привет, Хабр!
Меня зовут Евгений, и с недавних пор я являюсь членом команды развития инфраструктуры в Домклике. Больше всего опыта у меня в области сетевых технологий, в простонародье я «сетевик». На сегодняшний день наша команда, да и не только наша, активно прорабатывает возможность использования облачной инфраструктуры для создания резервного центра обработки данных (РЦОД). А раз я много лет занимаюсь сетями, то вполне логично, что мне стало интересно решить одну задачку, о которой я хочу вам поведать.
Если опустить первое и самое главное предубеждение относительно питонячьей многопоточности у большинства программистов — что её не существует из-за GIL, — то остается другое, и, наверное, вполне достоверное: что многопоточность — это сложно, и нам этого, пожалуйста, не надо. И знаете что? Так оно и есть. Многопоточность — это сложно, особенно когда выбираешься за пределы стандартных руководств и попадаешь со своей многопоточной поделкой в реальный мир. И, возможно, вам не нужно. Ни здесь, ни далее я не буду обсуждать целесообразность написания многопоточного кода на Python и сразу перейду к тому, как это делать.
Привет Хабр!
В этой статье я хочу поделится своими соображениями по поводу перспектив роста и развития «пожилых» (в возрасте более 40 лет) разработчиков. Статья будет полна субъективизма и антитолерантности, так что всем желающих похоливарить – добро пожаловать в комментарии.
Меня зовут Елизавета Добрянская и я Frontend-разработчица в компании Домклик.
В этой статье я хочу рассказать, как мы танцевали с бубном при настройке алертов на клиентские метрики. Как, зачем и с чем мы столкнулись в этой задаче - читайте далее 🙂
Шел 2021 год, русские хакеры продолжают переигрывать и уничтожать загнивающий Запад, вмешиваясь в выборы, ломая фейсбуки и пентагоны. Тем временем на Хабре выходят статьи о создании неубиваемых Kubernetes-кластеров, которые, по видимому, всех нас переживут. А кто-нибудь подумал о простых пацанах (пацанессах)??? Как быть обычному программисту, который хочет свой небольшой кластер и ламповый CI/CD с автодеплоем приложения, чтобы кенты с района не засмеяли?
Всем привет, меня зовут Алексей и я алкоголик разработчик на Python/Go в Домклик. Сегодня мы будем понижать порог входа в self-hosted Kubernetes и GitLab AutoDevops.
Меня зовут Алексей Казаков, я техлид команды «Клиентские коммуникации» в Домклик. По моему опыту подавляющее большинство приложений, взаимодействующих с базой данных, использовали для этого Object Relational Mapper. В этой статье я продолжу знакомить вас с популярными ORM, которые встречались мне в продовых проектах. На очереди всемогущий SQLAlchemy.
Привет, Хабр!
Сегодня я хотел бы рассказать о ряде практик, позволяющих оптимизировать загрузку и отрисовку изображений на сайте. Давайте рассмотрим, что мы может сделать на сегодняшний день помимо стандартных методик (компрессии и кеширования на клиенте).
Довольно часто я попадаю в ситуацию, когда мне нужно в моменте оценить длительность реализации реализации бизнес-фичи. Обычно это какая-нибудь рядовая встреча, на которой инициатор бизнес-идеи, резво размахивая руками в воздухе, рассказывает о своем предложении. В конце своего выступления, в котором часто много слов (но не цифр) сказано о том, зачем это фича нужна и какой эффект она даст, всегда звучит сакральный вопрос: «Когда сделаете эту великолепную доработку?»
Я хотел бы поделиться с читателем ходом своих рассуждений, которые позволяют мне довольно точно оценивать сроки реализации даже в самых запущенных случаях.
Разумеется, я не смогу предусмотреть и учесть все нюансы и специфики, принятые в различных компаниях в процессе разработки и вывода новой функциональности в эксплуатацию. Однако я верю, что описанные ниже практики будут полезны и вы сможете их адаптировать под свою ситуацию.
Сразу упомяну, что речь идет в первую очередь о продуктовых компаниях, где нет жесткого учета рабочего времени и можно подумать о качестве и поддерживаемости новой функциональности. В случае заказной разработки всё обычно гораздо сложнее и требует более детальной проработки.
Вместе с ростом кодовой базы растёт и порог входа, который надо преодолеть новичкам для полноценного погружения в проект. Также возникает ситуация, когда опытные сотрудники не знают, как работает часть механизмов в уже существующей системе. При естественных процессах текучки персонала бывает и так, что эксперты уходят из компании, а новички ещё не успели получить критически важные знания. В таком случае старая команда без обмена знаниями «умрёт»: новички не смогут разобраться в старом коде и не будут знать, почему было принято то или иное архитектурное решение, и это приведёт к переписыванию проекта.
Чтобы не допустить такой ситуации, необходимо на уровне компании в целом и команды в частности организовать обмен знаниями и постоянно поддерживать эту культуру. Ниже я приведу различные способы обмена и субъективно оценю их эффективность и сложность внедрения.
Python предоставляет программисту огромное пространство свободы. Увы, обычно это довольно дорогая в плане производительности свобода, зато при правильном применении иногда она позволяет творить сущую магию. Но сегодня мы поговорим не о таких вот «богоугодных» применениях свободы, а о том, что никогда не стоит использовать в прикладном программировании — о модификациях кода на уровне AST.
Будучи фанатом NBA (Национальная баскетбольная ассоциация), я тщательно слежу за новостями из-за океана: игры, обмены игроками, слухи и прочее. Но, как инженера, меня также привлекают различные прогнозы на основе математического анализа, статистические показатели, которые влияют на игру. Еще интересней, как информационные технологии меняют спорт. Дальше я расскажу, как один владелец команды из мира IT попытался поменять восприятие зрителями НБА на обычную ТВ-трансляцию.
Сейчас я работаю с несколькими командами разработки. В каждой из них есть менеджер, он же владелец продукта. В ежедневной работе я достаточно часто общаюсь с каждым из них. Раньше я работала внутри одной команды в качестве разработчика и техлида и взаимодействовала всегда только с одним менеджером. Поэтому относительно давно у меня появился определенный собирательный образ владельца продукта, с которым мне круто работать. И мне очень хочется, чтобы у каждой команды был такой менеджер.
Здравствуйте! Сегодня я хочу поведать вам свой путь становления как разработчика. Сейчас, на волне множества курсов и вездесущей рекламы «как войти в IT», много людей устремилось в эту бескрайнюю, интересную и очень непростую область. Я написал эту историю для них и для себя. Как некоторый взгляд в прошлое. На всё, что было сделано и чего это стоило. Кому интересно, прошу под кат.
Сперва немного о себе. Сейчас я работаю главным инженером по разработке в компании ДомКлик и отвечаю за создание внутренней BI-системы. Но, как вы поняли из заголовка статьи, так было далеко не всегда.