Пользователь
Системный аналитик — это новый чёрный в мире IT. На эту позицию заходят новички, бизнес-аналитики, опытные разработчики и даже менеджеры.
Войти в системную аналитику может (почти) каждый человек, не лишённый логики и интеллекта, а на 400+ слабо?
Составила полноценный туториал для подготовки к прохождению технического собеседования. С кейсами реальных собеседований, моими мыслями и выводами. Статей планируется несколько. Это обзорная — определиться с контекстом и пройтись по основным поинтам.
Монокультура в программировании — это использование одного стека для решения всех возникающих задач. Она существует не только на уровне конкретного человека и его предпочтений, но также часто встречается на уровне компаний. В таких компаниях, как правило, все делается с использованием одной технологии.
В далеком 2011 году в Ульяновске я начал создавать филиал широко известной в узких кругах компании Undev, той самой, которая писала софт для трансляции выборов президента, проведения ЕГЭ и многих других мероприятий. Основным стеком компании на тот момент был Ruby. Как известно, в регионах рубистов крайне мало, и на тот момент во всем Ульяновске это был десяток человек, которых все знали по именам.
Наша стратегия заключалась в том, чтобы брать ребят с других стеков и переучивать их, а также набирать зеленых студентов. По сути, это был обучающий центр при производстве. Занимался я этим примерно 4 года, за которые было выращено более 70 разработчиков только внутри Андева, не считая активностей, направленных на развитие среды (за это время в городе появилось еще несколько филиалов Руби-ориентированных компаний, и многие начали использовать Руби в дополнение к своим основным направлениям).
Первоначально идея развития состояла в том, что мы используем Руби почти везде (и js, конечно). Ведь это дает столько возможностей.
Одним из ключевых аспектов успешной разработки является эффективная отладка кода.
Статья посвящена настройке и использованию PhpStorm, Xdebug и Docker для отладки PHP-скриптов в Docker-контейнере. Статья предлагает актуальную информацию (на момент написания) и оформлена в виде подробнейшего пошагового туториала. Информация действительна для ОС Windows. В других ОС возможны варианты.
Цель статьи — не просто создать пошаговой конспект настроек, а объяснить, как всё это взаимодействует. Это поможет избежать затруднений при изменении интерфейса IDE в будущем. Возможно, статья выглядит слишком педантичной. Но гуру всегда смогут прочесть её по диагонали, зато новички в этой теме найдут для себя много полезного.
По мнению Артема Закируллина*, одна из фундаментальных проблем, с которой сталкиваются разработчики при анализе кода – высокая когнитивная нагрузка. Это не абстрактное, а реальное ограничение возможностей, которое стоит времени и денег. На чтение и понимание кода, тратится больше времени, чем на его написание. Поэтому, разработчику нужно постоянно задаваться вопросом: не пишет ли он код, чтение которого создает чрезмерную когнитивную нагрузку?
Подробнее о том, с какими проблемами от высокой когнитивной нагрузки сталкиваются разработчики и какие решения помогут упростить понимание кода для последующей работы с ним читайте под катом.
*Обращаем ваше внимание, что позиция автора может не всегда совпадать с мнением МойОфис.
Современный цифровой мир насыщен самыми разными веб-сервисами — социальными сетями, мессенджерами, агрегаторами услуг, маркетплейсами, досками объявлений и облачными хранилищам. Этими платформами пользуются сотни миллионов пользователей. Созданием и развитием таких систем занимаются специалисты различных профилей. Однако, из-за специфики их проектирования, разработки, тестирования и обслуживания, найти на рынке специалистов, полностью готовых к подобной работе, непросто. Обычно их приходится обучать и дообучать уже в процессе работы.
В контексте сказанного магистратура «Распределенные веб-сервисы» — совместная программа VK Education и Института прикладных компьютерных наук ИТМО — предоставляет возможность для IT-специалистов овладеть необходимыми навыками для успешной карьеры в одной из самых перспективных областей. Программе недавно исполнился год, и сегодня мы расскажем о её преимуществах и особенностях, а также поделимся опытом студентов программы.
Как и многие языки программирования, Rust призывает разработчика определенным способом обрабатывать ошибки. Вообще, существует два общих подхода обработки ошибок: с помощью исключений и через возвращаемые значения. И Rust предпочитает возвращаемые значения.
В этой статье мы намерены подробно изложить работу с ошибками в Rust. Более того, мы попробуем раз за разом погружаться в обработку ошибок с различных сторон, так что под конец у вас будет уверенное практическое представление о том, как все это сходится воедино.
В наивной реализации обработка ошибок в Rust может выглядеть многословной и раздражающей. Мы рассмотрим основные камни преткновения, а также продемонстрируем, как сделать обработку ошибок лаконичной и удобной, пользуясь стандартной библиотекой.
В мире фронтенд-разработки существует множество различных фреймворков, которые помогают сделать процесс создания веб-приложений более удобным и эффективным. Я являюсь частью этого мира уже более 4-х лет, сейчас занимаю должность фронтенд разработчика в компании Loyalty Labs. За все время в IT я познакомилась с разными инструментами и фреймворками, и хотела бы обсудить трёх "гигантов" в области frontend: React, Angular и Vue.
Эта статья не предназначена для того, чтобы обучать вас этим фреймворкам. Это не технический гайд. Здесь я поделюсь своим мнением, попытаюсь разобраться в особенностях и понять, чем каждый из этих "гигантов" может гордиться.
Привет! Меня зовут Павел, я программист-эксперт в отделе разработки серверных решений ЮMoney. Сегодня расскажу и покажу, как менялись наши конечные автоматы в бэкенде — как от большого страшного монстра с файлами классов по 1000+ строк мы пришли к красивым визуальным диаграммам, которые понимают не только разработчики, но и сотрудники других отделов.
Эта статья является конспектом книги «Designing Data-Intensive Applications».
В предыдущем конспекте мы рассмотрели «грязную» операцию чтения – это разновидность состояния гонки, возникающая при попытке конкурентной записи в одни объекты различными транзакциями. К этой категории проблем также относится ситуация потери обновления.
Однако на этом список возможных состояний гонки, возникающих при конкурентных операциях записи не заканчивается. В этом конспекте рассмотрим более сложные примеры конфликтов и то, как с ними бороться. Далее затронем изоляцию уровня сериализуемости, в том числе различные методы, которые обеспечивают сериализуемость. И в конце подведем итоги по транзакциям.
С увеличением сложности ИТ-систем все больше становится очевидной ограниченность привычных реализаций с простой архитектурой компонентов. Особенно это заметно в случае систем, которые должны стабильно работать с большими и интенсивными нагрузками.
Чтобы понять это, достаточно рассмотреть механику разворачивания большинства высоконагруженных систем. Например, разобрать построение системы авторизации пользователей для последующей сквозной аналитики авторизации/аутентификации между связанными сервисами компании.
Разбираемся на примере клиентского кейса, как может выглядеть такая система в части хранения данных, почему для таких задач оптимальна комбинация реляционной БД и Tarantool, а также показываем, какие показатели может обеспечить система с Tarantool.
Почти у каждой компании, которая пропагандирует микросервисную архитектуру, под капотом лежит кусок устаревшего монолита. И его все еще нужно поддерживать. Разработчики, создавшие эти системы, уже не работают в компании, а документация отсутствует либо устарела. Как проводить интеграционное тестирование в таких условиях?
В моем опыте был случай, когда интеграция представляла собой связку около 15 систем, каждая из которых имела свою базу данных. Все сервисы разворачивались в k8s вручную, тестовые данные были неконсистентны, интеграции между сервисами приходилось настраивать вручную самостоятельно. Ни один сервис нельзя было замокать: каждый элемент влиял на тестируемую бизнес-логику. Я просто познавала дзен, разбираясь во внутреннем устройстве систем и следуя заранее составленному тест-плану.
Меня зовут Катя Назмеева, сейчас я тестирую бэк в Lamoda Tech. В статье я предложу стратегии для успешного проведения интеграционного тестирования микросервисов и расскажу про инструменты, которые могут облегчить этот процесс. Обсудим, как организовать все таким образом, чтобы интеграционное тестирование не создавало задержек в новых релизах — и не заставляло QA страдать.
Здравствуй, хабр! Что-то я давно не писал, отбился от рук, а ведь когда-то мы целый курс машинного обучения на Хабре вели. Расскажу про свой недавний заход по собесам, что спрашивали, какие выводы сделал. Контекст: Applied Machine Learning science (в том числе этот ваш Generative AI), Нидерланды, уровень синьор+. Я долго получал отказы, старался не унывать и в конце таки нашил лычку Staff GenAI Field Solutions Architect в Google Cloud. Тут поделюсь статистикой собесов, полезными ресурсами и, конечно, всякими советами.
В новом переводе от команды Spring АйО, Siva Katamreddy, девелопер адвокат в AtomicJar (Testcontainers), поделился своими мыслями о популярных в наши дни TDD, Clean, Hexagonal, Onion и Ports & Adapters. Он также постарался ответить на вопрос, который, возможно, волнует не только его: "Действительно ли мы, разработчики, так любим всё усложнять?".
Когда мы постепенно переводим легаси систему на новые рельсы, возникает множество случаев, когда само легаси и то, чем мы его заменяем должны взаимодействовать. Поскольку внесение изменений в легаси — это всегда долго, дорого и сложно, нам нужен механизм, который сможет интегрировать возможности новой системы, минимизируя при этом воздействие на легаси. Разбираемся, как можно использовать паттерн «Перехват Событий», чтобы пересылать их в новую систему.
Когда я первый раз услышал про .NET Aspire, я подумал что это какая-то очередная лажа от Майкрософта, про которую все забудут через неделю.
Особенно, учитывая какую дичь часто завозят в шарп (например те же ужасно спроектированные Primary Constructor'ы про которые я писал, или вот прикол-пропозал от самого Тоуба). Так что ожидания у меня, честно говоря, были ниже нуля.
Но попробовав его лично, я был, честно говоря, шокирован. Трепещите, жависты!! Трепещите гошники! Трещепищите питонисты - такого вы еще точно не видели.
Я даже представить не мог, что DevEx можно сделать настолько офигительным.
