Как стать автором
Обновить
-7
0
Клёпов Алексей @XelaVopelk

Пользователь

Отправить сообщение

Практическое DDD. Часть 1: Создание правильных основ

Время на прочтение 8 мин
Количество просмотров 12K

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

Читать далее
Всего голосов 13: ↑10 и ↓3 +7
Комментарии 4

Это БАЗА: 4 правила управления проектами для проджект-менеджеров

Время на прочтение 10 мин
Количество просмотров 15K

Часто задерживаетесь на работе, количество задач растет в геометрической прогрессии, сроки проектов постоянно приходится сдвигать? Тогда эта статья для вас: расскажу о 4 главных ошибках, которые совершают руководители проектов, приводящие к таким последствиям. На примерах разберём эти ошибки, откуда они берутся и как их не допускать.

Читать далее
Всего голосов 12: ↑10 и ↓2 +8
Комментарии 7

Грань выбора. Учимся строить временные петли на F# при помощи Hopac.Alt. Часть 1. Развилка

Время на прочтение 15 мин
Количество просмотров 1.8K

Hopac -- самостоятельный асинхронный движок, написанный специально под F#.
Он стоит на 4 китах, одним из которых является перенаправление потоков вычисления через явное противопоставление конкурирующих задач.

Конкурирующие задачи (или ветки) реализуются через концепцию альтернатив (или Alt), которую я хочу осветить в этом цикле из трёх статей.

Читать далее
Всего голосов 2: ↑2 и ↓0 +2
Комментарии 2

Что нам стоит диаграмму в Python построить: 5 вариантов привлекающей внимание визуализации данных и кое-что ещё

Время на прочтение 6 мин
Количество просмотров 12K

Диаграммы помогают визуализировать как простые, так и самые сложные наборы данных. При этом диаграмм — множество видов, у каждого есть свои достоинства и недостатки. О наиболее эффектных и эффективных, реализуемых с Python, мы решили рассказать в сегодняшней подборке. Если вам интересна эта тема – просим под кат. А если у вас есть собственные предпочтения среди графиков (или вы используете что-то ещё), то пишите в комментариях, обсудим. Что же – поехали!

Читать далее
Всего голосов 24: ↑24 и ↓0 +24
Комментарии 5

Как в 3 раза снизить затраты на отказоустойчивую инфраструктуру, переехав с Hazelcast на Redis

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 6.1K

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

Читать далее
Всего голосов 29: ↑28 и ↓1 +27
Комментарии 18

Функциональные и НЕфункциональные задачи

Время на прочтение 4 мин
Количество просмотров 1.7K

Не тот стрелок, кто стреляет, а тот, кто попадает

Теперь, когда мы знаем, что такое задача и что не является задачей, думаю, стоит изучить, какие задачи являются функциональными, а какие - НЕфункциональными?

В управлении потоком задач существует проблема разделения задач на функциональные и НЕфункциональные.

Функциональные задачи — это такие задачи, выполнение которых на определённом промежутке времени фактически продвигает нас к достижению заданных — желаемых целевых результатов — целей.

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

Если мы хотим достичь целевых результатов, то нам надо выявлять и выполнять функциональные задачи, а не отказываться от них. Не пытаться их проигнорировать или избежать. Не выполнение функциональных задач — всегда означает не достижение целей. Отказ от них — отказ от цели.

Часто выполнению функциональных задач нам мешают НЕфункциональные задачи.

И красно, и пестро, да пустоцветом

НЕфункциональные задачи — это противоположность функциональных задач. Это те задачи, которые на текущем отрезке времени никакого вклада в достижение заданных — желаемых целевых результатов не делают.

Они в текущем периоде времени никак не связаны с целями организации, не ведут к достижению этих целей или даже противоречат им. Их невыполнение никак не повлияет на достижение целей.

Читать далее
Всего голосов 10: ↑3 и ↓7 -4
Комментарии 4

Чем заняться тимлиду, если не кодить? Рассказываю о своих задачах

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 11K

Моя предыдущая статья вызвала довольно бурное обсуждение на тему, кто такой тимлид и чем он занимается, поэтому в этой статье я хотел рассказать о том, чем занимаюсь я.

Вообще задачи тимлида могут сильно отличаться в разных компаниях. В моем опыте обычно было так: чем меньше в команде представлено ролей, тем больше задач будет у тимлида. Я как-то работал с тимлидом, которому приходилось даже тестировать, потому что в команде не было тестировщика.

Я составил список своих задач и разбил их на категории. Кстати говоря, добрую половину этих задач я повесил на себя сам.

Читать далее
Всего голосов 21: ↑19 и ↓2 +17
Комментарии 13

Лучшая задача по программированию для собеседования

Время на прочтение 7 мин
Количество просмотров 62K

Готовиться к собеседованию можно по-разному: смотреть ролики на YouTube, читать документацию, положиться на судьбу и тд. В большинстве случаев кандидатам предложат решить одну или несколько задач. В этой статье вас ждет подробный разбор реальной задачки, рекомендации к ее решению и объяснение ожиданий интервьюера от кандидатов.

Читать далее
Всего голосов 68: ↑45 и ↓23 +22
Комментарии 271

В чем разница между unit и компонентным тестированием

Время на прочтение 4 мин
Количество просмотров 8.5K

И почему вас это должно волновать.

При компонентном тестировании вы тестируете более ранние этапы процесса разработки, и вместо тестирования всего приложения (или его большого фрагмента) вы тестируете более мелкие части приложения. С точки зрения Shift Left это очень важно.

Читать далее
Всего голосов 5: ↑4 и ↓1 +3
Комментарии 2

Архитектурные изменения: важно не терять темпа и воли к улучшению ситуации

Уровень сложности Простой
Время на прочтение 5 мин
Количество просмотров 1.3K

Последнее время я достаточно часто участвую в проектах, где надо не придумать архитектуру с нуля, а исправить то, что уже придумали и уже почти год-два-три разрабатывают. Желающих и что более важно убедительно рассказывающих как правильно делать дизайн архитектуры большой системы с нуля полно. По разным причинам, далеко не всегда такое заканчивается успешным релизом. Так сложилось, уже, наверное, последние лет 6-7, 80% моей активности это участие в проектах где «мы тут придумали классную систему и год над ней работаем, а теперь надо чтобы она заработала». Симптомы почти в каждом таком проекте одни и те же

симптомы ...
Всего голосов 3: ↑3 и ↓0 +3
Комментарии 0

Организация внутреннего митапа в ИТ-компании: ожидание VS реальность

Уровень сложности Простой
Время на прочтение 8 мин
Количество просмотров 4.4K

Во многих ИТ-компаниях популярен формат внутренних митапов — встреч, на которых специалисты обсуждают особенности своей работы, обмениваются опытом и знаниями, просто общаются. Митап более неформален, чем тематическое собрание или внутренняя конференция, и идеально подходит для нетворкинга. Но при этом нельзя сказать, что митап — дружеские посиделки под пиво (хотя, конечно, в каких-то компаниях так и есть). Организация такого мероприятия не так проста, как кажется на первый взгляд, и требует определённых последовательных шагов.

Под катом рассказываем, с чем мы столкнулись при подготовке первого внутреннего митапа МойОфис, что у нас в итоге получилось и какие мы сделали выводы.

Читать далее
Всего голосов 39: ↑36 и ↓3 +33
Комментарии 1

Код-ревью: cookbook от Google

Уровень сложности Простой
Время на прочтение 16 мин
Количество просмотров 12K

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

От автора перевода: в Google вместо PR (Pull Request) принято использовать аббревиатуру CL (ChangeList — список изменений). Остальные термины, на мой взгляд, понятны и без пояснений. Чтобы разбавить кучу текста, в качестве разделителей разделов использованы генерации на тему "код-ревью от разных мультипликаторов" от нейросети Kandinsky.

Читать далее
Всего голосов 8: ↑7 и ↓1 +6
Комментарии 5

Mela: асинхронный фреймворк на Python для сервисов, работающих с RabbitMQ

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 5.3K

WARNING: длинная вступительная часть. Если хотите перейти сразу к делу - листайте до Getting Started.

Читать далее
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 4

Уровни английского языка: детальный разбор критериев в 2023

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 43K

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

Читать далее
Всего голосов 19: ↑16 и ↓3 +13
Комментарии 4

Всё, что вы не знали о CAP теореме

Время на прочтение 7 мин
Количество просмотров 120K
Во время моего первого опыта работы с распределенными системами я постоянно сталкивался с некой CAP-теоремой, пришлось изрядно покопать, чтобы изучить и осознать её со всех сторон. Я не являюсь мастером баз данных, но надеюсь, что мое маленькое исследование мира распределённых систем будет полезно для обычных разработчиков. В статье я расскажу о том, что такое CAP, его проблемы и альтернативы, а также рассмотрим некоторые популярные системы баз данных через CAP призму.
Читать дальше →
Всего голосов 28: ↑28 и ↓0 +28
Комментарии 9

Мини-справочник и руководство по Scrum

Время на прочтение 8 мин
Количество просмотров 116K
Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.
Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса
— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum


Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.
Читать дальше →
Всего голосов 33: ↑29 и ↓4 +25
Комментарии 23

Как составить стратегическую карту компании по методу «снизу-вверх»

Уровень сложности Простой
Время на прочтение 9 мин
Количество просмотров 5.8K

Стратегические карты — один из инструментов стратегического планирования. Они помогают решить, какие задачи на ближайшее время компания признаёт приоритетными, и наглядно их представить на одной схеме.

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

Научиться рисовать стратегические карты
Всего голосов 1: ↑1 и ↓0 +1
Комментарии 6

Мы же всё протестировали, или откуда берутся баги на проде (часть 1)

Уровень сложности Простой
Время на прочтение 12 мин
Количество просмотров 15K

“Критичный баг на проде!”

Это сообщение в рабочем мессенджере, пожалуй, самый страшный сон тестировщика/QA-специалиста.

Я в тестировании уже больше 10 лет, попробовала себя в разных ролях на 40+ проектах.

И в этой статье рассмотрю ТОП-5 наиболее распространенных причин появления багов на проде, которые НЕ зависят напрямую от тестировщиков. С примерами и анализом, как этих багов избежать.

Статья написана на основе реального опыта: моего и моих коллег-тестировщиков.

Читать далее
Всего голосов 17: ↑15 и ↓2 +13
Комментарии 25

Как на самом деле работает Async/Await в C# (Часть 7)

Уровень сложности Сложный
Время на прочтение 13 мин
Количество просмотров 10K

Несколько недель назад в блоге «.NET Blog» появилась статья «Что такое .NET, и почему вы должны выбрать его?». В нем был представлен высокоуровневый обзор платформы, кратко описаны различные компоненты и архитектурные решения, а также обещаны более подробные посты по затронутым темам. Этот пост является первым таким продолжением, в котором подробно рассматривается история создания, архитектурные решения и детали реализации async/await в C# и .NET.

Disclaimer: Я не являюсь профессиональным переводчиком, перевод подготовлен скорее для себя и коллег. Я буду благодарен за любые исправления и помощь в переводе, статья очень интересная давайте сделаем её доступной на русском языке.

Читать далее
Всего голосов 14: ↑14 и ↓0 +14
Комментарии 1

Обеспечение безопасности Frontend приложений

Уровень сложности Простой
Время на прочтение 13 мин
Количество просмотров 14K

Безопасность является важным фактором при создании frontend приложений, поскольку они часто являются отправной точкой для атак. Я решил собрать в одну статью основные меры, которых стоит придерживаться или о которых хотя бы нужно задуматься.

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

Читать далее
Всего голосов 16: ↑15 и ↓1 +14
Комментарии 6

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность

Специализация

Software Architect, Database Developer