Каждый системный и бизнес-аналитик проходит "боевое крещение" в своей карьере, когда получает первую задачу на проектирование интеграций. Звучит серьезно и сложно. И это так, если ни разу не работал с таким видом задач.

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

В первой части мы рассмотрели базовые операции, такие как добавление новых атрибутов, создание индексов и ограничений и т.д.

Эта статья посвящена двум более сложным миграциям:

- обновление большой таблицы
- разделение таблицы на две

Рассмотрим подходы, которые позволяют провести миграции с минимальным простоем для приложения.

Продолжаю цикл статей по разработке ETL-процессов на Python. На этот раз мы преобразуем синхронный etl-процесс из статьи Пишем ETL-процесс на Python в асинхронный.

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

Перед тем, как начать, буквально пару слов о себе. Меня зовут Роман Лунев, я руковожу отделом бэкенд-разработки в команде развития суперприложения ВКонтакте. Разработкой занимаюсь более 10 лет, а собеседования провожу уже порядка 6–7 лет. За это время я много раз успешно заваливал, а потом, с опытом, и успешно проводил собеседования как интервьюер. А ещё насмотрелся на косяки коллег, потому что время от времени погружал в этот процесс интервьюеров-новичков. А это даёт очень много пищи для размышлений. Расскажу про свой план собеседования.

MVP –  это minimum VIABLE product: минимально жизнеспособный продукт. Но почему зачастую происходит так, что вместо minimum VIABLE получается minimum VALUABLE — минимально полезный? 

Рассказываем, что такое MVP, почему не всегда удается сделать именно минимально жизнеспособный продукт и на что стоит обратить внимание если проект едет в сторону minimum VALUABLE.

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

Поэтому в управление проектами всегда должна входить работа с рисками. Поиск их причин и вариантов предотвращения. Иначе одно непредвиденное обстоятельство может погубить весь ваш проект.

Привет! Меня зовут Никита Калинский, я разработчик в Тинькофф Бизнесе. Сейчас я занимаюсь продуктом под названием «Лента операций». Физлица в желтом приложении могут отслеживать все свои операции, и мы делаем такой же инструмент для предпринимателей.

Сегодня я хочу поговорить про основы различных систем исполнения эффектов в Scala. Мы разберем, как работают системы эффектов, как они реализованы в Scala в Cats Effects и ZIO и как эволюционировали между версиями. А также обсудим неявные особенности и подводные камни исполнения сред таких библиотек.

«Не понимаю нашего будущего» — если вы слышите такое внутри вашей компании, то, возможно, вам просто необходима стратегическая сессия.

По крайней мере такое решение я, как scrum master и Agile coach определила внутри нашего коллектива, когда столкнулась с такими высказываниями во время обсуждений на ретроспективах и других встречах. Коллектив, на примере которого я предлагаю вам сегодня разобрать опыт ведения стратегической сессии, – gamedev паблишер, где работают продюсеры, маркетологи, аналитики, копирайтеры и другие специалисты.

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

«Вы заметили, какое сейчас время? Новая эра, новая эпоха. Век открытых, доступных знаний – было бы желание, как говорится. Все больше и больше людей как будто просыпаются, выходят из длительного сна, состояния стагнация»¹ - цитата из книги.

Вопрос грейдов всегда волнует тех, кто занимается разработкой ПО. Как понять самому, а главное доказать руководству, что ты находишься на новом уровне со всеми вытекающими последствиями? Многие из нас интроверты, и идти доказывать что-то кому-то – мало кто хочет. Как убрать фактор “хороших отношений” с руководством у коллег? Да и вообще хочется объективности и прозрачности критериев. Именно этим мы руководствовались в “Рексофт”, когда задумывали такой инструмент как “Матрица компетенций” (МК). Именно про него я хочу вам немного рассказать. Разберёмся в том, что это такое и с чем его едят. Чтобы не быть голословным, посмотрим на реальный пример матрицы, которая активно используется в компании. Возьмем матрицу компетенций Android-программиста, которую я (Олег Иванов, руководитель группы мобильной разработки компании «Рексофт») когда-то составил и стараюсь поддерживать в актуальном виде.

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

Ещё дадим несколько советов на тот случай, если всё-таки не удаётся показать результат за отведённое время.

Готовьтесь

Привет! Меня зовут Александр Токмаков, я Head of Product в СберМаркете. Сегодня я хочу обсудить с вами приоритизацию. Я считаю, что это один из главных скиллов в работе продакта, а если ты работаешь в крупной компании — точно главный. Именно поэтому я полюбил приоритизировать, разобрался во фреймворках и выработал свою систему, которая показывает крутой результат: >30% наших фичей улучшают продукт. 

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

Почему вы выбрали фреймворк Scrum, а не метод управления проектами Kanban? Не можете ответить? Значит — лично вы Scrum и не выбирали. Кто-то сделал это за вас.

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

«Чтобы сотрудник выполнил задачу, ты должен думать, как сотрудник, ты должен чувствовать, как сотрудник, ты должен сам стать сотрудником!» Именно так захотелось переделать фразу из сериала «Секретные материалы» при написании этой статьи:)

Не всегда все идет так, как мы хотим. Задачи не выполняются: срываются сроки, качество выполнения не удовлетворяют ожиданиям. Возникают мысли «Что за бездарности и почему они не могут сделать нормально?». Знакомо?

Раскрою небольшой секрет – вся причина в нас самих! И сейчас я вам это докажу!

Давайте попробую визуализировать и доказать вам, почему именно вы ответственный за постановку задачи? Как вы влияете на её выполнение чужими руками? А дальше поделюсь методом успешной постановки задач.

2 мая 2023 года Modular (одна из компаний-лидеров в сфере AI-инфраструктуры) анонсировала язык программирования Mojo, обещающий полную совместимость с Python в сочетании со сверх-высокой производительностью.

В компании утверждают, что автоматическое низкоуровневое распараллеливание, возможности строгой типизации и статической компиляции уже на самых ранних этапах развития языка позволяют достичь скорости, превосходящей Python в 35 000 раз!

Так что это за чудо-язык такой, правда ли он заменит Python — да и где его пощупать можно?