Интернет — удивительное изобретение человечества, и мы привыкли, что оно ещё и бесплатное. Да, конечно, все мы платим за подключение, создание и содержание сайтов, но сам интернет-сёрфинг никогда не требовал с нас денег, да и выход в интернет через браузеры тоже свободен.
Но так ли это задумывалось изначально?
Мы проанализировали спрос на ИТ-специалистов в России за период с сентября 2022 года по сентябрь 2023 года. Одни из самых востребованных вакансий — системные и бизнес аналитики, менеджеры проектов и продуктов, а также Java-разработчики.
Мы побеседовали с руководителем направления системного программирования в «Криптоните» Александром Авраменко о карьерном пути Rust-разработчика, особенностях языка Rust и его применении к моделям машинного обучения в высоконагруженных системах.
Периодически встречающаяся проблемами кода на С и C++ являются утечки памяти и неопределенное поведение. Даже если вы используете умные указатели, то от ошибок в библиотеках сторонних разработчиков вы не застрахованы. Для поиска ошибок в коде существуют специальные инструменты: санитайзеры и valgrind. Однако, не вся информация об ошибках имеет для нас ценность, рассмотрим методы её фильтрации.
Все, кто сталкивался с версткой писем, знают, что там по-прежнему используется табличная верстка, инлайновые стили, css хаки, устаревшие теги и т.д. И все это ради поддержки всех (или, вернее сказать, большинства) почтовых клиентов: различных версий Outlook, веб-интерфейсов почтовиков и мобильных почтовых клиентов.
Но индустрия не стоит на месте - все активнее для верстки писем применяются емейл-фреймворки. О них и пойдет речь дальше. Сравним 2 из них: MJML и TJML framework (хотел добавить еще и Zurb Foundation for email, но они в последних публикациях уже не говорят о поддержке outlook, да и в принципе устарели).
MJML - самый известный и популярный емейл-фреймворк, признанный сообществом. На его основе работают всевозможные визуальные емейл-билдеры, и по факту он является стандартом в зарубежном емейл-маркетинге, хотя в России не все о нем знают.
TJML- это мой емейл-фреймворк, который создавался на основе личного многолетнего опыта работы в сфере емейл-маркетинга. В нем я постарался учесть все те проблемы и сложности, с которыми сталкивается верстальщик писем. Идея была в том, чтобы не просто обеспечить “приемлемое отображение” в большинстве клиентов”, а дать свободу верстальщику, при этом не обременяя его вопросами совместимости с устаревшими почтовыми клиентами. Ну и, плюс ко всему, дать возможность заложить в единый код как html, так и AMP-версию письма. Но в этой статье речь пойдет пока что только о html.
Чтобы сравнить эти емейл-фреймворки, сверстаем следующее письмо, а потом посмотрим на получившийся код и качество отображения в различных почтовых клиентах.
Дети растут, их потребности меняются, а проверенные рецепты семейного счастья перестают действовать. Особенно изобретательным приходится быть в праздники и в летнее время. Как организовать совместный досуг, чтобы всем было интересно? Ранее я уже писал, как играть с ребёнком в шифры , а также давал подборку развивающих настолок. В честь Дня защиты детей решил продолжить эту славную традицию.
Мой вариант — занять ребёнка чем-то созидательным, что привлекает его сейчас и поможет в будущем. Нам не пришлось долго выбирать. Поскольку я айтишник, в качестве хобби занимающийся ремонтом разных железок, дочка часто видит меня с мультиметром и паяльником. Она горит желанием помочь, но что тут можно доверить пятилетнему ребёнку? Оказывается, многое! Нужно только правильно организовать процесс.
Привет, Хабр! Меня зовут Георгий Осипов. Я работаю в МГУ и компании Яндекс, а также в команде курса «Разработчик С++» Яндекс Практикума. В этой статье я поделюсь своими мыслями о том, почему немолодой язык С++ до сих пор не теряет актуальности.
Кажется, что первое доказательство — новость 2022 года, когда компания Google анонсировала новый язык Carbon. Он должен стать альтернативой C++. Первая версия Carbon выйдет только через 2-3 года, но уже сейчас понятно — если C++ языку ищут замену, значит, её нет.
Все знают, как разрабатывать продукты для клиентов. Другое дело, когда задачу в разработку приносят не продакты, а коллеги из других команд: например, хотят автоматизировать свои процессы или внедрить новую систему.
Они остаются наедине со своими проблемами. Идут к разработчикам — те просят ТЗ от аналитиков. Идут к аналитикам — те просят требования от службы безопасности, и это только начало.
После того как проект описан, нужно выбить ресурсы на его разработку, доказать его важность и эффективность. Для многих коллег не из IT это неподъемные задачи.
Внутри Lamoda Tech мы задумались о том, как не забивать на такие идеи. Эти проекты могли бы ускорить процессы и принести значительную выгоду компании. Но они редко доходят до реализации: слишком много усилий для этого нужно приложить. Большинство заказчиков сходят с дистанции задолго до финиша.
Под Новый Год мы с женой пересматриваем одну популярную магическую сагу — хочется знаете ли в жизни волшебства. В IT волшебства тоже хватает — от танцев с бубнами до самых современных технологий, принцип работы которых проще объяснить тёмной магией. Так, например, бытует мнение, что настройка service mesh — это магия, подвластная лишь волшебникам DevOps. Но у нас в Альфа-Банке разработчики исторически не маглы, а, как минимум, полукровки, поэтому имеют право приобщиться к волшебному миру.
В этой серии статей я хочу поделиться опытом изучения технологии service mesh, а именно Istio, на примере практической задачи, возникшей какое то время назад в одной из систем Альфа Банка, системным архитектором которой я являюсь.
В первой статье я расскажу о наших архитектурных подходах, породивших задачу, а также в подробностях, со схемами и примерами, покажу как мы ее решали и с какими трудностями столкнулись.
Вторая статья будет посвящена нагрузочному тестированию и выводам об эффективности полученного решения.
Привет! Меня зовут Мялкин Максим, я занимаюсь мобильной разработкой в KTS.
Мы в мобильной команде для шаринга кода на несколько платформ используем KMP.
На Хабре можно встретить достаточное количество статей по этой технологии, но большинство из них рассматривает выбор кроссплатформенной технологии либо перевод проекта на KMP.
В этой статье я расскажу наш опыт взаимодействия с KMP со стороны iOS-разработки: проблемы, с которыми столкнулись, их решение, наш подход, и главное — как к этой технологии относятся iOS-разработчики.
Меня зовут Виктор, я backend-разработчик в финансовом маркетплейсе Банки.ру.
Последние годы я интересуюсь темой умного дома. Хочу поделиться тем, с чего я начинал и к чему пришел. Эта статья будет полезна тем, кто: хочет понять как устроен self-hosted умный дом; хочет перенять опыт и избежать чужих ошибок; уже имеет умный дом и интересуется прикладными сценариями.
Есть на свете особо ценные приёмы и инструменты, применимые почти к любой профессии. И речь не о пресловутых софт-скилах, с ними всё достаточно очевидно. Куда интереснее поговорить о «жёстких» навыках, которые, за счёт своей универсальности, здорово прокачивают профессиональную эрудицию и не только.
В этой статье мы займемся созданием файловой системы на NodeJS + TypeScript в пользовательском пространстве, которая будет управлять изображениями пользователей. Она будет преобразовывать их в различные форматы, изменяя размеры и предоставляя уникальные бинарные данные изображения при каждом чтении — ведя себя при этом как стандартная файловая система.
Если вам интересна данная тема, добро пожаловать под кат.
Привет, сегодня будет объёмная и обстоятельная статья о низкоуровневом профилировании и дигностике производительности. Многократно в комментариях к докладам и статьям пользователи высказывали пожелание увидеть не просто перечисление шаблонов "как нужно" и "как не нужно", а целостную историю. Поэтому вот вам статья про конкретный кейс и его историю :). Не удивляйтесь, что начнём мы с JPA, хотя казалось бы где оно и где ассемблер. По ходу дела вы всё поймёте.
Работа врача поистине тяжелая. Для того, чтобы облегчить ее и сделать чуточку проще, попробовал с помощью «No‑code» разработать удобное приложение, по подобию доставки. Что из этого вышло и почему бессмысленно.
Всем привет! Меня зовут Максим, я руководитель одной из групп эксплуатации инфраструктурных сервисов в Ozon. Наша команда занимается поддержкой и развитием нескольких базовых сервисов компании, одним из которых, по историческим причинам, является сервис разрешения доменных имен (DNS).
В Ozon много различных сервисов и систем. Они общаются друг с другом и внешним миром по доменным именам. DNS — центральное звено, без которого не обходится почти ни одна инфраструктура. Понятно, что когда DNS отдаёт некорректные данные, то это неприятно, когда таймаутит — плохо, когда прилёг — очень плохо, когда прилёг надолго — в принципе, можно расходиться. Значит, одна из основных задач команды инфраструктуры — обеспечить сервисам надёжное и, желательно, быстрое разрешение доменных имён. Об этом мы и поговорим. Также затронем вопросы управления ресурсными записями, жизнь в Multi DC-среде, обслуживание DNS, кеширование, журналирование запросов и возможные проблемы.
Статья может быть полезна коллегам, интересующимся эксплуатацией, архитектурой и высокой доступностью сервисов, да и просто может быть любопытна как история построения инфраструктурной единицы в крупной компании.
В сети вы можете найти множество статей на тему «UML мертв», «Почему системным аналитикам не нужен UML» и множество подобного. Работая на протяжении последних 15 лет в совершенно разных компаниях, с совершенно разным жизненным циклом приложений и систем, с различной структурой и методологиями разработки я вижу одно и тоже — попытки ускорения time‑to‑market за счет отказа от процесса управления требованиями, подаваемые под разными прекрасными аргументами, приводят 100% компаний к необходимости переписывать приложения не потому, что оно не отвечает требованиям, а потому что «никто не знает как или почему оно так работает».
Важной проблемой отказа от нормального процесса управления требованиями является то, что разрабатываемые без этого процесса приложения и системы получаются абсолютно не гибкими и даже элементарнейшие, с точки зрения заказчиков, изменения приводят к запуску полного цикла разработки.
Можно перечислить еще огромное количество проблем, к которым приводит разработка без модели требований.
У меня, как и у многих, довольно много чатов в телеграмме. Иногда просто нет времени (а иногда и не хочется) отвечать на некоторые сообщения. Именно так возникла идея создания виртуального клона. В статье рассматривается простая идея, состоящая в том, чтобы зафайнтюнить языковую модель на личных сообщениях, выгруженных из Telegram-чатов. Возможно, в дальнейшем такой клон сможет общаться за вас
Рано или поздно каждый продуктовый дизайнер сталкивается с вопросом: нужно ли ему уметь программировать? Есть краткий ответ: дизайнеру не обязательно уметь программировать, но давайте копнём глубже.
Под продуктовым дизайнером в статье имеется в виду дизайнер цифровых продуктов, UI/UX-дизайнер, и остальные подходящие названия, которые сейчас в ходу на рынке.