Любимые шрифты для разработки
Помимо применения всяких линтеров, хочется, чтобы код визуально нравился. Я обычно использую шрифт FiraCode с лигатурами. Обычные символы ==, >=, ->, != и многие другие становятся очень красивенькими и более читаемыми.
В репозитории собраны все подробности с картинками и пояснениями.
#tools
Помимо применения всяких линтеров, хочется, чтобы код визуально нравился. Я обычно использую шрифт FiraCode с лигатурами. Обычные символы ==, >=, ->, != и многие другие становятся очень красивенькими и более читаемыми.
В репозитории собраны все подробности с картинками и пояснениями.
#tools
GitHub
GitHub - tonsky/FiraCode: Free monospaced font with programming ligatures
Free monospaced font with programming ligatures. Contribute to tonsky/FiraCode development by creating an account on GitHub.
Как сделать из линейного сотрудника начальника
В статье описывается интересный гайд по превращению опытного бекендера в тимлида. Начинается история с препятствий — чем будет плох разработчик, ставший руководителем. Он будет пытаться решить проблемы привычным ему образом, то есть тянуть все процессы на себя путём увеличения количества своей работы. Это плохо и бизнесу, и коллегам, и самому разработчику.
Как сделать правильно? Автор предлагает очевидные, но хорошие шаги:
— объяснить, что от него нужно на должности тимлида
— договориться о конкретных задачах, сроках, не забыть выдать ресурсы
— дождаться выполнения и помочь в процессе
— провести ретроспективу. Кстати, это важный этап жизни любой команды, но здесь речь про ретро с самим тимлидом. Надо совместно понять, насколько цели достигнуты и что надо подкорректировать
У автора совершенно выпадает вопрос определения или развития софтскиллов, требуемых тимлиду, чтобы адекватно вести команду. Вероятно, предполагается, что вы удачно взяли среди разработчиков некоторого неформального лидера, у которого уже есть склонность к руководству, и работаете с ним. Иначе гайд вам никак не поможет, разработчик-интроверт с достаточно малой вероятностью сможет стать крутым руководителем.
#edu
В статье описывается интересный гайд по превращению опытного бекендера в тимлида. Начинается история с препятствий — чем будет плох разработчик, ставший руководителем. Он будет пытаться решить проблемы привычным ему образом, то есть тянуть все процессы на себя путём увеличения количества своей работы. Это плохо и бизнесу, и коллегам, и самому разработчику.
Как сделать правильно? Автор предлагает очевидные, но хорошие шаги:
— объяснить, что от него нужно на должности тимлида
— договориться о конкретных задачах, сроках, не забыть выдать ресурсы
— дождаться выполнения и помочь в процессе
— провести ретроспективу. Кстати, это важный этап жизни любой команды, но здесь речь про ретро с самим тимлидом. Надо совместно понять, насколько цели достигнуты и что надо подкорректировать
У автора совершенно выпадает вопрос определения или развития софтскиллов, требуемых тимлиду, чтобы адекватно вести команду. Вероятно, предполагается, что вы удачно взяли среди разработчиков некоторого неформального лидера, у которого уже есть склонность к руководству, и работаете с ним. Иначе гайд вам никак не поможет, разработчик-интроверт с достаточно малой вероятностью сможет стать крутым руководителем.
#edu
Хабр
Как сделать из линейного сотрудника начальника и потом с этим жить
И так, вот команда растёт, растёт и дорастает хотя бы до 15+ человек. В этот момент вы неожиданно понимаете, что у вас 3 бекенд-разработчика или даже 5. Здесь возникает неудержимое желание сделать...
Я люблю питон, и вот почему он меня бесит
Специалист выделяется тем, что для своего инструмента он понимает сильные и слабые стороны. Поэтому прошу: статья про кривые и косые вещи в питоне.
Автор подсвечивает существующие проблемы генераторов: откладывают выполнение кода, дают мало контекста и затрудняют отладку.
Динамические импорты дают свободу (как удобно прямо в функции что-то для отладки импортировать и потом убрать), так и определённые боли. А если импорт упадёт, а вы импортировали в рантайме? Это точно не то, что вы бы хотели.
Интересно было прочитать про legacy с потоками и процессами. Выглядит забавно.
Микс из разных стандартов именований прямо в модуле logging стандартной библиотеки забавен. Я всегда тыкаю в logging, когда хочу показать camelCase :)
С async в python действительно непросто. Но у нас был достаточно хороший гайд на этот счёт, вливайтесь.
Обратите внимание на блок про символьный ад. Меня всегда веселило, что 1 является числом, (1) тоже просто число, а 1, (с запятой) уже кортеж. Кстати, вы знали, что создание списка с помощью [] немного быстрее, чем создание с помощью list()?
С указанными автором нюансами про декораторы никогда не сталкивался. А вы? А вот с необходимостью прервать с помощью break сразу два цикла сталкивался неоднократно. Приходится некрасиво костылить, к сожалению.
Про наличие map/filter одновременно с comprehensions автор немного недоговаривает. В целом не существенно, но в статье List Comprehension vs Map этот вопрос рассматривается подробнее.
Огромная боль, что нет аннотации исключений. Я как-то советовал новичкам для обработки исключений смотреть справку по функции и самому в docstring тщательно прописывать исключения. А потом я посмотрел справку на open. В описании есть только порождение IOError. А на самом деле функция open может выбрасывать угодно — IsADirectoryError, PermissionError, FileNotFoundError... И узнать это нельзя.
Какие WTF в питоне больше всего забавляют вас?
#python
Специалист выделяется тем, что для своего инструмента он понимает сильные и слабые стороны. Поэтому прошу: статья про кривые и косые вещи в питоне.
Автор подсвечивает существующие проблемы генераторов: откладывают выполнение кода, дают мало контекста и затрудняют отладку.
Динамические импорты дают свободу (как удобно прямо в функции что-то для отладки импортировать и потом убрать), так и определённые боли. А если импорт упадёт, а вы импортировали в рантайме? Это точно не то, что вы бы хотели.
Интересно было прочитать про legacy с потоками и процессами. Выглядит забавно.
Микс из разных стандартов именований прямо в модуле logging стандартной библиотеки забавен. Я всегда тыкаю в logging, когда хочу показать camelCase :)
С async в python действительно непросто. Но у нас был достаточно хороший гайд на этот счёт, вливайтесь.
Обратите внимание на блок про символьный ад. Меня всегда веселило, что 1 является числом, (1) тоже просто число, а 1, (с запятой) уже кортеж. Кстати, вы знали, что создание списка с помощью [] немного быстрее, чем создание с помощью list()?
С указанными автором нюансами про декораторы никогда не сталкивался. А вы? А вот с необходимостью прервать с помощью break сразу два цикла сталкивался неоднократно. Приходится некрасиво костылить, к сожалению.
Про наличие map/filter одновременно с comprehensions автор немного недоговаривает. В целом не существенно, но в статье List Comprehension vs Map этот вопрос рассматривается подробнее.
Огромная боль, что нет аннотации исключений. Я как-то советовал новичкам для обработки исключений смотреть справку по функции и самому в docstring тщательно прописывать исключения. А потом я посмотрел справку на open. В описании есть только порождение IOError. А на самом деле функция open может выбрасывать угодно — IsADirectoryError, PermissionError, FileNotFoundError... И узнать это нельзя.
Какие WTF в питоне больше всего забавляют вас?
#python
Хабр
Я люблю питон, и вот почему он меня бесит
Вас приветствует ваш зануда! Если вы следите за моей ленивой активностью, то заметили бы, что у меня много от чего пригорает. Вот, например: У меня пригорает от низкосортных статей на потоке: Питон...
Подкаст DevFM: Ретроспектива силами команды разработки
Мы тут собрались с духом и решили записать подкастик. Обсудили интересную и насущную тему – ретроспективы.
У нас нет специального человека для ретро, да и сама идея этого мероприятия многим кажется сомнительной. Мы поделились опытом, как проводим ретро своими силами и почему считаем его важной штукой.
#devfm #podcast #teamwork
Мы тут собрались с духом и решили записать подкастик. Обсудили интересную и насущную тему – ретроспективы.
У нас нет специального человека для ретро, да и сама идея этого мероприятия многим кажется сомнительной. Мы поделились опытом, как проводим ретро своими силами и почему считаем его важной штукой.
#devfm #podcast #teamwork
Пятничное развлекательное
Посмотрите короткий ролик WAT — A lightning talk by Gary Bernhardt from CodeMash 2012. Товарищ обращает внимание на совершенно безумные конструкции в ruby и javascript и их нелогичность.
Что будет, если выполнить
Что вернёт конструкция
Если вам понравилось, то к просмотру предлагается 20-минутный доклад Brian Leroux - WTFJS на схожую тематику.
#fun
Посмотрите короткий ролик WAT — A lightning talk by Gary Bernhardt from CodeMash 2012. Товарищ обращает внимание на совершенно безумные конструкции в ruby и javascript и их нелогичность.
Что будет, если выполнить
a = a
?Что вернёт конструкция
[] + []
? Массив плюс массив в js. А массив плюс объект? А операция плюс коммутативна или нет?Если вам понравилось, то к просмотру предлагается 20-минутный доклад Brian Leroux - WTFJS на схожую тематику.
#fun
YouTube
dotJS 2012 - Brian Leroux - WTFJS
Filmed in Paris on Nov 30th, 2012. More talks on http://dotconferences.eu
Суперкомпьютерные дни в России
Началась такая конференция. В этом году я не выступаю, а только слушаю. Сама конференция не такая крутая, как highload, поэтому публичной трансляции нет. Трансляция только после платной регистрации. В комментариях дам свои ссылки для ознакомления.
Кстати, мы писали, зачем вообще имеет смысл ходить на конференции.
Велкам на кофе-брейк, если кто-то тоже тут :)
Началась такая конференция. В этом году я не выступаю, а только слушаю. Сама конференция не такая крутая, как highload, поэтому публичной трансляции нет. Трансляция только после платной регистрации. В комментариях дам свои ссылки для ознакомления.
Кстати, мы писали, зачем вообще имеет смысл ходить на конференции.
Велкам на кофе-брейк, если кто-то тоже тут :)
Telegram
DevFM
Зачем нужны конференции
Современная конференция это:
0. Пополнение пула решённых задач. Если столкнетесь с похожей ситуацией, то будете владеть готовым решением с его плюсами и минусами. Это существенно повышает вашу ценность как специалиста
1. Свежая информация…
Современная конференция это:
0. Пополнение пула решённых задач. Если столкнетесь с похожей ситуацией, то будете владеть готовым решением с его плюсами и минусами. Это существенно повышает вашу ценность как специалиста
1. Свежая информация…
Managing difficult software engineers
Фокус статьи на управлении проблемными разработчиками. Это логично, потому что с беспроблемными разработчиками всё просто работает.
Тем не менее, общие рекомендации для простого случая тоже есть. Формула такая:
–Trust. Доверяйте компетенции сотрудника, давайте разумную автономию и адекватно относитесь к ошибкам
– Growth. Давайте разработчику расти, выдавая ему крутые задачи, поощряйте успех и давайте обратную связь
– Comfort. Обеспечьте комфорт, в том числе минимизируйте прерывания и обеспечьте процесс. Чем меньше у разработчика болит голова по вопросам вне проекта, тем более он может быть продуктивен в проекте
Дальше рассматриваются типичные проблемные персонажи: Прокрастинатор, Одинокий волк, Демотиватор (как вам такой перевод? В оригинале negative Nancy), Обещатель, Всезнайка, Тихоня, Перфекционист, Ненадёжный, Конфликтный, Выгоревший. По каждому даны признаки и советы, как с таким жить.
Советы для одинокого волка просто слёзы. Типа сделайте его командным игроком, ага. По остальным всё выглядит по делу.
#edu
Фокус статьи на управлении проблемными разработчиками. Это логично, потому что с беспроблемными разработчиками всё просто работает.
Тем не менее, общие рекомендации для простого случая тоже есть. Формула такая:
–Trust. Доверяйте компетенции сотрудника, давайте разумную автономию и адекватно относитесь к ошибкам
– Growth. Давайте разработчику расти, выдавая ему крутые задачи, поощряйте успех и давайте обратную связь
– Comfort. Обеспечьте комфорт, в том числе минимизируйте прерывания и обеспечьте процесс. Чем меньше у разработчика болит голова по вопросам вне проекта, тем более он может быть продуктивен в проекте
Дальше рассматриваются типичные проблемные персонажи: Прокрастинатор, Одинокий волк, Демотиватор (как вам такой перевод? В оригинале negative Nancy), Обещатель, Всезнайка, Тихоня, Перфекционист, Ненадёжный, Конфликтный, Выгоревший. По каждому даны признаки и советы, как с таким жить.
Советы для одинокого волка просто слёзы. Типа сделайте его командным игроком, ага. По остальным всё выглядит по делу.
#edu
Vadim Kravcenko
Managing difficult software engineers
Effectively managing difficult employees in a software engineering context hinges on three core principles: fostering trust by empowering autonomy, promoting growth through challenges and constructive feedback, and ensuring a comfortable work environment…
Backup: август и сентябрь
Мы записали подкаст! Совместное обсуждение разных тем всегда было для нас источником взаимного вдохновения. Мы решили попробовать новый для себя жанр и записали наш разговор: встречайте выпуск Ретроспектива силами команды разработки
Остальное, как обычно, в текстовом виде.
Я люблю питон, и вот почему он меня бесит
Базы данных
Посмотрите на keydb
Временные интервалы в postgres
Управляем людьми
Как сделать из линейного сотрудника начальника
Managing difficult software engineers
Инструменты
Утилита lazy-docker
Любимые шрифты для разработки
Если пропустили, то подборка за июнь и июль
#backup
Мы записали подкаст! Совместное обсуждение разных тем всегда было для нас источником взаимного вдохновения. Мы решили попробовать новый для себя жанр и записали наш разговор: встречайте выпуск Ретроспектива силами команды разработки
Остальное, как обычно, в текстовом виде.
Я люблю питон, и вот почему он меня бесит
Базы данных
Посмотрите на keydb
Временные интервалы в postgres
Управляем людьми
Как сделать из линейного сотрудника начальника
Managing difficult software engineers
Инструменты
Утилита lazy-docker
Любимые шрифты для разработки
Если пропустили, то подборка за июнь и июль
#backup
Как проектировать бизнес-логику приложения?
Вопрос подписчика: с ростом сложности разработки возникает необходимость в проработке логики приложения и будущего интерфейса. Есть ли какие-то приложухи, приёмы, фреймворки, тулзы для помощи в создании абстракций будущего проекта? Слышал про UML-диаграммы, но хочется уточнить, что сейчас в сфере разработки действительно применимо, что нужно и что не нужно.
----------
При нашем участии создавались проекты от месяца до полутора лет и коллективами от 1 до 10 участвующих лиц. Были мы и рядовыми разработчиками, и тимлидами, и даже чисто создавали ТЗ для дальнейшей реализации сторонними силами. По нашему опыту проектной работы, функционал приложения удобно излагать в техническом задании (ТЗ). Подробное ТЗ в текстовом виде содержит набор требуемых фич и покрывает нюансы вроде разграничения ролей, планируемых интеграций и так далее. Само ТЗ можно компоновать по-разному. Довольно удачным является описание через раскрытие сценариев работы приложения. Оттолкнуться можно от user story – это краткое описание функциональности в стиле "возможность добавлять тег к задаче". В ТЗ такую фичу надо детализировать: кто именно может добавлять тег? Теги фиксированные или настраиваются? Настраиваются пользователем или админом приложения? На какие экраны надо выводить тег и где их можно редактировать? Ответы на эти вопросы складываются в кучу нюансов. Удобнее всего описывать ТЗ по экранам будущего приложения, а потом рядом прописать сценарии работы, в каком порядке эти экраны позволят выполнить те самые user story. При этом не надо из ТЗ пытаться делать огромный бюрократический документ. Размер, конечно, зависит от сложности системы, но вот наполнять ТЗ канцеляризмами совсем зло. Формальные подходы типа UML, на наш взгляд, в индустрии не взлетели.
После ТЗ или одновременно с ним неплохо бы нарисовать макеты будущего приложения. Они упрощают восприятие ТЗ и позволяют согласовывать отдельные элементы с широким кругом заинтересованных лиц. Посмотреть картинку приложения куда проще, чем читать ТЗ. Нужные элементы, то есть условные формочки, выпадающие списки и кнопочки нужно накидать на будущие экраны. Сразу становится понятно, не перегружены ли экраны избыточной функциональностью. Рисовать макеты можно хоть от руки, хоть в paint. Конечно, есть более подходящие инструменты вроде figma, но глобально можно использовать что любой инструмент. Figma предоставляет разные библиотеки элементов и берёт на себя вопросы расшаривания макетов – макеты можно отдать дизайнеру, который в фигме же прорисует нормальный интерфейс, из которого потом верстальщик перенесёт всё в код. Дальше вопрос объёма приложения и опыта. Условно, если в paint макет я отрисую за 10 часов, а в figma за 1 час, казалось бы, paint совсем плох. Но! Для освоения figma я потрачу кучу времени, условные 4 часа. Тогда соотношение времени уже не 1 к 10, а 1 к 2. Плюс, сколько всего времени займут макеты? Обычно это относительно малая часть работы. По нашему опыту, для приложения со сроком разработки в год на ТЗ и макеты выделяется меньше 1 месяца, большая часть из которого тратится на выяснение фич и их согласование с заказчиком.
#devfm #systemdesign
Вопрос подписчика: с ростом сложности разработки возникает необходимость в проработке логики приложения и будущего интерфейса. Есть ли какие-то приложухи, приёмы, фреймворки, тулзы для помощи в создании абстракций будущего проекта? Слышал про UML-диаграммы, но хочется уточнить, что сейчас в сфере разработки действительно применимо, что нужно и что не нужно.
----------
При нашем участии создавались проекты от месяца до полутора лет и коллективами от 1 до 10 участвующих лиц. Были мы и рядовыми разработчиками, и тимлидами, и даже чисто создавали ТЗ для дальнейшей реализации сторонними силами. По нашему опыту проектной работы, функционал приложения удобно излагать в техническом задании (ТЗ). Подробное ТЗ в текстовом виде содержит набор требуемых фич и покрывает нюансы вроде разграничения ролей, планируемых интеграций и так далее. Само ТЗ можно компоновать по-разному. Довольно удачным является описание через раскрытие сценариев работы приложения. Оттолкнуться можно от user story – это краткое описание функциональности в стиле "возможность добавлять тег к задаче". В ТЗ такую фичу надо детализировать: кто именно может добавлять тег? Теги фиксированные или настраиваются? Настраиваются пользователем или админом приложения? На какие экраны надо выводить тег и где их можно редактировать? Ответы на эти вопросы складываются в кучу нюансов. Удобнее всего описывать ТЗ по экранам будущего приложения, а потом рядом прописать сценарии работы, в каком порядке эти экраны позволят выполнить те самые user story. При этом не надо из ТЗ пытаться делать огромный бюрократический документ. Размер, конечно, зависит от сложности системы, но вот наполнять ТЗ канцеляризмами совсем зло. Формальные подходы типа UML, на наш взгляд, в индустрии не взлетели.
После ТЗ или одновременно с ним неплохо бы нарисовать макеты будущего приложения. Они упрощают восприятие ТЗ и позволяют согласовывать отдельные элементы с широким кругом заинтересованных лиц. Посмотреть картинку приложения куда проще, чем читать ТЗ. Нужные элементы, то есть условные формочки, выпадающие списки и кнопочки нужно накидать на будущие экраны. Сразу становится понятно, не перегружены ли экраны избыточной функциональностью. Рисовать макеты можно хоть от руки, хоть в paint. Конечно, есть более подходящие инструменты вроде figma, но глобально можно использовать что любой инструмент. Figma предоставляет разные библиотеки элементов и берёт на себя вопросы расшаривания макетов – макеты можно отдать дизайнеру, который в фигме же прорисует нормальный интерфейс, из которого потом верстальщик перенесёт всё в код. Дальше вопрос объёма приложения и опыта. Условно, если в paint макет я отрисую за 10 часов, а в figma за 1 час, казалось бы, paint совсем плох. Но! Для освоения figma я потрачу кучу времени, условные 4 часа. Тогда соотношение времени уже не 1 к 10, а 1 к 2. Плюс, сколько всего времени займут макеты? Обычно это относительно малая часть работы. По нашему опыту, для приложения со сроком разработки в год на ТЗ и макеты выделяется меньше 1 месяца, большая часть из которого тратится на выяснение фич и их согласование с заказчиком.
#devfm #systemdesign
Посмотрите на альтернативу Kafka
Мы очень любим Кафку и писали на эту тему несколько постов. Но не Кафкой единой. Всегда интересно посмотреть на альтернативы. И самая интересная сейчас — red panda.
А для, тех кто заинтересовался подробностями — сложная статья с множеством бенчмарков и описанием интересных проблем. Обязательно загляните в заключение, там автор делает некоторые выводы и сравнивает Redpanda с Kafka.
#skills
Мы очень любим Кафку и писали на эту тему несколько постов. Но не Кафкой единой. Всегда интересно посмотреть на альтернативы. И самая интересная сейчас — red panda.
А для, тех кто заинтересовался подробностями — сложная статья с множеством бенчмарков и описанием интересных проблем. Обязательно загляните в заключение, там автор делает некоторые выводы и сравнивает Redpanda с Kafka.
#skills
Telegram
DevFM
Брокер сообщений Apache Kafka
Начать изучение рекомендуем со статьи Apache Kafka: основы технологии от ребят из slurm, в которой покрыты:
— отличия кафки от остальных сервисов очередей
— базовые компоненты kafka
— основные принципы работы
Для опытных пользователей…
Начать изучение рекомендуем со статьи Apache Kafka: основы технологии от ребят из slurm, в которой покрыты:
— отличия кафки от остальных сервисов очередей
— базовые компоненты kafka
— основные принципы работы
Для опытных пользователей…
Значимость второстепенных навыков специалиста
Вопрос подписчика: получается, мне, как разработчику, стоит освоить фигму и научиться писать ТЗ? На месте бизнесмена, при прочих равных, на работу я бы взял разработчика, который умеет в фигму. Получается, что он владеет большим пулом инструментов, скорее всего, он эффективнее и быстрее разберётся с новым инструментом, плюс, если завтра помрёт ui-дизайнер, запряжём этого чувака наклепать что-нибудь съедобное.
----------
В вакууме так и есть, чем больше навыков у сотрудника, тем лучше. Но дальше начинаются нюансы. В стартапе или малом бизнесе, действительно, востребованы специалисты широкого профиля. Обычно владелец этого бизнеса и разработчик, и бухгалтер, и курьер, и макеты рисует. Но найм устроен несколько по-другому. У сотрудника есть должностные обязанности, и грузить его непрофильной работой не очень здорово. У человека падает мотивация, и результат выходит так себе. Более того, если перевести в деньги. Условный разработчик стоит 200к тугриков в месяц, а условный дизайнер 80к. Просто не эффективно использовать разработчика не по назначению.
Переложим ответ на другой пример. Если вы нанимаете каменщика для укладки печки, будете ли вы интересоваться его умением играть на гитаре? Не думаю. При этом его опыт строительства домов может быть полезен, он тогда сможет порекомендовать место установки печи или подобрать правильный способ вывода печной трубы. Второстепенные навыки могут как дополнять инструментарий специалиста, так и никак на него не влиять. Для backend-разработчика знание figma дополнительной ценности, кажется, не привносят.
Если вы только начинаете свой путь в профессии, то важно попробовать разные роли. Вдруг вы станете крутым дизайнером интерфейсов? Или у вас скрытая любовь к техническому писательству, и ТЗ станет для вас отдушиной? Чтобы найти своё место в мире, надо попробовать разные варианты. По хорошему, институт должен такую возможность предоставлять.
#devfm #edu
Вопрос подписчика: получается, мне, как разработчику, стоит освоить фигму и научиться писать ТЗ? На месте бизнесмена, при прочих равных, на работу я бы взял разработчика, который умеет в фигму. Получается, что он владеет большим пулом инструментов, скорее всего, он эффективнее и быстрее разберётся с новым инструментом, плюс, если завтра помрёт ui-дизайнер, запряжём этого чувака наклепать что-нибудь съедобное.
----------
В вакууме так и есть, чем больше навыков у сотрудника, тем лучше. Но дальше начинаются нюансы. В стартапе или малом бизнесе, действительно, востребованы специалисты широкого профиля. Обычно владелец этого бизнеса и разработчик, и бухгалтер, и курьер, и макеты рисует. Но найм устроен несколько по-другому. У сотрудника есть должностные обязанности, и грузить его непрофильной работой не очень здорово. У человека падает мотивация, и результат выходит так себе. Более того, если перевести в деньги. Условный разработчик стоит 200к тугриков в месяц, а условный дизайнер 80к. Просто не эффективно использовать разработчика не по назначению.
Переложим ответ на другой пример. Если вы нанимаете каменщика для укладки печки, будете ли вы интересоваться его умением играть на гитаре? Не думаю. При этом его опыт строительства домов может быть полезен, он тогда сможет порекомендовать место установки печи или подобрать правильный способ вывода печной трубы. Второстепенные навыки могут как дополнять инструментарий специалиста, так и никак на него не влиять. Для backend-разработчика знание figma дополнительной ценности, кажется, не привносят.
Если вы только начинаете свой путь в профессии, то важно попробовать разные роли. Вдруг вы станете крутым дизайнером интерфейсов? Или у вас скрытая любовь к техническому писательству, и ТЗ станет для вас отдушиной? Чтобы найти своё место в мире, надо попробовать разные варианты. По хорошему, институт должен такую возможность предоставлять.
#devfm #edu
Футбольная аналитика: что поменялось за 2 года
Статья является продолжением истории, где из костылей и верёвочек создавалась система видеоаналитики для детских футбольных школ. Она позволяет отслеживать игроков и определять их различные количественные характеристики: среднюю/максимальную скорость и пробег за матч. Такая попытка добавить геймификации, одновременно создав инструмент отслеживания прогресса обучающихся.
Со своим решением по видеоаналитике автор дошёл из детских спортивных команд до профессионального спорта. Оказалось, что клубам нужно оцифровать каждого игрока, чтобы понимать его ценность, прогресс в тренировках, параметры (как в RPG) и возможности на поле. И на пути возник ряд интересных проблем. В статье высокоуровнево объясняется тракт работы комплекса, затем показываются проблемы реального мира, которые решены или предстоит решить. Ценность статьи именно в бизнесовом взгляде на проблемы. Есть такая беда, вот набор вариантов решения в совершенно разных плоскостях.
Интересно, что не удалось уйти от ручного допиливания статистики. Сказано, что на 5 минут игры приходится от 300 до 1500 спорных пересечений, которые оператор размечает от 3 до 10 секунд каждое. Итого выходит примерно полтора часа, если 1000 пересечений и 5 секунд на каждое.
Вообще Milfgard пишет о разном, наша подборка любопытных статей его авторства тут.
#edu
Статья является продолжением истории, где из костылей и верёвочек создавалась система видеоаналитики для детских футбольных школ. Она позволяет отслеживать игроков и определять их различные количественные характеристики: среднюю/максимальную скорость и пробег за матч. Такая попытка добавить геймификации, одновременно создав инструмент отслеживания прогресса обучающихся.
Со своим решением по видеоаналитике автор дошёл из детских спортивных команд до профессионального спорта. Оказалось, что клубам нужно оцифровать каждого игрока, чтобы понимать его ценность, прогресс в тренировках, параметры (как в RPG) и возможности на поле. И на пути возник ряд интересных проблем. В статье высокоуровнево объясняется тракт работы комплекса, затем показываются проблемы реального мира, которые решены или предстоит решить. Ценность статьи именно в бизнесовом взгляде на проблемы. Есть такая беда, вот набор вариантов решения в совершенно разных плоскостях.
Интересно, что не удалось уйти от ручного допиливания статистики. Сказано, что на 5 минут игры приходится от 300 до 1500 спорных пересечений, которые оператор размечает от 3 до 10 секунд каждое. Итого выходит примерно полтора часа, если 1000 пересечений и 5 секунд на каждое.
Вообще Milfgard пишет о разном, наша подборка любопытных статей его авторства тут.
#edu
Хабр
Футбольная аналитика: что поменялось за 2 года
Пару лет назад я рассказывал, как мы трекаем движения игроков на поле, что помогает очень круто оцифровать тренировки детей (в наших футбольных школах). Потом оказалось, что это нужно футбольным...
RESTful web API design
У Майкрософта есть годный гайд по проектированию RESTful веб-API. Там и фундаментальные вещи, и конкретные рекомендации:
— во главу угла ставить ресурс, а не действие. Не делать ручку create-order, вместо неё делать POST-запрос на
— стараться не усложнять ручку больше, чем двойная вложенность
— приводятся типовые HTTP-методы. Нередко достаточно GET/POST/DELETE, можно добавить PUT и PATCH. К сожалению, часто семантика этих запросов понимается всеми по-разному. В этом гайде представлено довольно практичное описание. По каждому методу даны нюансы как по применению, так и по особенностям реализации в части возврата ошибок и асинхронным операциям. Важно не забывать про идемпотентность (пост о ней) некоторых методов
— не забыта постраничная навигация в запросе, HATEOAS и версионирование API
#systemdesign
У Майкрософта есть годный гайд по проектированию RESTful веб-API. Там и фундаментальные вещи, и конкретные рекомендации:
— во главу угла ставить ресурс, а не действие. Не делать ручку create-order, вместо неё делать POST-запрос на
orders/<id>
. При этом подчёркивается, что внутреннее представление данных не должно просачиваться наружу. То есть за сущностью orders может быть несколько сущностей реальной базы данных— стараться не усложнять ручку больше, чем двойная вложенность
collection/item/collection
, например, /customers/<id>/orders
. При этом следует найти баланс. С одной стороны, запросы лучше экономить (много запросов = больше нагрузка на сервер и клиент), но при этом на каждый чих слать весь мир в ответе тоже не стоит— приводятся типовые HTTP-методы. Нередко достаточно GET/POST/DELETE, можно добавить PUT и PATCH. К сожалению, часто семантика этих запросов понимается всеми по-разному. В этом гайде представлено довольно практичное описание. По каждому методу даны нюансы как по применению, так и по особенностям реализации в части возврата ошибок и асинхронным операциям. Важно не забывать про идемпотентность (пост о ней) некоторых методов
— не забыта постраничная навигация в запросе, HATEOAS и версионирование API
#systemdesign
Docs
Web API design best practices - Azure Architecture Center
Learn best practices for designing web APIs that support platform independence and service evolution.
Да, у нас есть тесты. А толку?
50-минутное закрытое видео про тесты с конференции PiterPy от Николая Хитрова. Начинается видео с лирики и мемов, а потом разгоняется и проходит по ключевым темам с кучей ссылок на полезные тулзы. Покрытые темы:
— Концепция AAA (Arrange-Act-Assert) и линтер flake8-aaa
— Переход к GWT (Given-When-Then) и интересный способ применения тест-классов для группировки пользовательских сценариев. Кстати, впервые я вижу понятное объяснение преимуществ GWT, потому что в большинстве источников ставят равенство между AAA и GWT
— Что должны проверять тесты и как dirty-equals вам может помочь. Тут же предлагаются библиотеки для декларативной проверки сложных структур
— Snapshot asserts для сложных данных с библиотеками syrupy и assertpy
— Фикстуры, их область применения и полезные инструменты вроде построения графа фикстур pytest-fixture-tools
— Инструменты для борьбы с нестабильными (flaky) тестами
— Инструменты для генерации данных в тестах, в том числе генерации тесты по контракту
— Обсуждение классической пирамиды тестов E2E, интеграционных и юнит-тестов
— Какие зависимости в тестах мокать, а какие запускать при тестах
— Плотно обсуждаются mock-и и stub-ы
— Тулзы для профилирования и ускорения тестов за счёт параллельного запуска или запуска только изменённого кода
#python #youtube
50-минутное закрытое видео про тесты с конференции PiterPy от Николая Хитрова. Начинается видео с лирики и мемов, а потом разгоняется и проходит по ключевым темам с кучей ссылок на полезные тулзы. Покрытые темы:
— Концепция AAA (Arrange-Act-Assert) и линтер flake8-aaa
— Переход к GWT (Given-When-Then) и интересный способ применения тест-классов для группировки пользовательских сценариев. Кстати, впервые я вижу понятное объяснение преимуществ GWT, потому что в большинстве источников ставят равенство между AAA и GWT
— Что должны проверять тесты и как dirty-equals вам может помочь. Тут же предлагаются библиотеки для декларативной проверки сложных структур
— Snapshot asserts для сложных данных с библиотеками syrupy и assertpy
— Фикстуры, их область применения и полезные инструменты вроде построения графа фикстур pytest-fixture-tools
— Инструменты для борьбы с нестабильными (flaky) тестами
— Инструменты для генерации данных в тестах, в том числе генерации тесты по контракту
— Обсуждение классической пирамиды тестов E2E, интеграционных и юнит-тестов
— Какие зависимости в тестах мокать, а какие запускать при тестах
— Плотно обсуждаются mock-и и stub-ы
— Тулзы для профилирования и ускорения тестов за счёт параллельного запуска или запуска только изменённого кода
#python #youtube
YouTube
Николай Хитров — Да, у нас есть тесты. А толку?
Ближайшая конференция — PiterPy 2024, 18 сентября (онлайн), 26-27 сентября, Санкт-Петербург.
Подробности и билеты: https://jrg.su/yKU46C
— —
Кандидаты часто спрашивают на собеседованиях, принято ли в команде писать тесты. И ответ в духе «да, мы пишем тесты»…
Подробности и билеты: https://jrg.su/yKU46C
— —
Кандидаты часто спрашивают на собеседованиях, принято ли в команде писать тесты. И ответ в духе «да, мы пишем тесты»…
Пятничное развлекательное
Южный парк долгое время является источником любимых приколов. Местами жестковато, как в серии "Скотт Тенорман должен умереть", местами очень весело, как в 20 сезоне с общим сюжетом про троллей в интернете. Кстати, идея с общей сюжетной линией Южном парке мне не зашла. Самостоятельные серии ценны тем, что их можно пересматривать вразнобой, а не сезон целиком.
В серии S13E03 Margaritaville стёбно описывается современное состояние инвестиций в мире. Годно подсвечена неадекватность рынка и финансовых институтов.
Посмотрите отрывок И... их нет (оригинал) про 100$, вложенных Стэном в банк. "Это очередь только для клиентов банка". А часть серии про определение стоимости актива в банке — это просто мем, пусть и жестковатый. Бедная курица.
Какая ваша любимая серия Южного парка?
#fun
Южный парк долгое время является источником любимых приколов. Местами жестковато, как в серии "Скотт Тенорман должен умереть", местами очень весело, как в 20 сезоне с общим сюжетом про троллей в интернете. Кстати, идея с общей сюжетной линией Южном парке мне не зашла. Самостоятельные серии ценны тем, что их можно пересматривать вразнобой, а не сезон целиком.
В серии S13E03 Margaritaville стёбно описывается современное состояние инвестиций в мире. Годно подсвечена неадекватность рынка и финансовых институтов.
Посмотрите отрывок И... их нет (оригинал) про 100$, вложенных Стэном в банк. "Это очередь только для клиентов банка". А часть серии про определение стоимости актива в банке — это просто мем, пусть и жестковатый. Бедная курица.
Какая ваша любимая серия Южного парка?
#fun
YouTube
South Park - S13E03. Margaritaville. Отрывок "И... их нет"
Решил тут подтянуть базу и прочитать книгу по скрам от самого создателя этой методологии. Называется “Революционный метод управления проектами”, Джеф Сазерленд. Вроде много где используем скрам, но было интересно узнать, а как оно всё таки задумывалось? Чтожжжж. Пожалуй, книга будет иметь какую-то маломальскую пользу, если вы никогда не слышали о скрам методологии. В остальном абсолютно графоманское произведение.
Что хорошего читали по методологиям?
#edu
Что хорошего читали по методологиям?
#edu
www.livelib.ru
Книга «Scrum. Революционный метод управления проектами»
Книга основателя методики Scrum, которая поможет вам реализовывать проекты в несколько раз быстрее и эффективнее.
Возможно, историки будущего... Читать дальше...
Возможно, историки будущего... Читать дальше...
Redis меняет лицензию
Как-то мы пропустили новость момент, что redis очередной раз поменял лицензию (нужен VPN). Эта лицензия (RSALv2 и SSPLv1) делает редис, как говорит автор заметки, source available – звучит так себе. Основное ограничение – запрет на бесплатное использование redis для облачных сервисов, то есть борьба с SaaS от крупных компаний вроде Amazon.
Наверняка новая лицензия не затронет большинство пользователей. Но лицензия является проприетарной и ещё черт ногу сломит разобраться, насколько это повлияет конкретно на вас. Да и в целом такие шаги с нашей точки зрения дурно попахивают.
Поэтому есть повод посмотреть на достойные форки редиса, которые стали уже ничуть не хуже. Об одном из них писали ранее – KeyDB, второй достойный вариант – DragonflyDB.
#tools
Как-то мы пропустили новость момент, что redis очередной раз поменял лицензию (нужен VPN). Эта лицензия (RSALv2 и SSPLv1) делает редис, как говорит автор заметки, source available – звучит так себе. Основное ограничение – запрет на бесплатное использование redis для облачных сервисов, то есть борьба с SaaS от крупных компаний вроде Amazon.
Наверняка новая лицензия не затронет большинство пользователей. Но лицензия является проприетарной и ещё черт ногу сломит разобраться, насколько это повлияет конкретно на вас. Да и в целом такие шаги с нашей точки зрения дурно попахивают.
Поэтому есть повод посмотреть на достойные форки редиса, которые стали уже ничуть не хуже. Об одном из них писали ранее – KeyDB, второй достойный вариант – DragonflyDB.
#tools
Redis
Redis Adopts Dual Source-Available Licensing - Redis
Beginning today, all future versions of Redis will be released with source-available licenses. Read more on the blog.
Вот так да! Любопытно будет посмотреть.
YouTube
Telegram Creator on Elon Musk, Resisting FBI Attacks, and Getting Mugged in California
Subscribe to our new Telegram channel: https://www.tg-me.com/TuckerCarlsonNetwork
The social media app Telegram has over 900 million users around the world. Its founder Pavel Durov sat down with us at his offices in Dubai for a rare interview.
Watch more here: …
The social media app Telegram has over 900 million users around the world. Its founder Pavel Durov sat down with us at his offices in Dubai for a rare interview.
Watch more here: …
Backdoor длиною в два года
Для тех кто пропустил детективную новость – бекдор в пакете архиватора XZ Utils, который повсеместно используется в Linux. Уязвимость предоставляет возможность выполнить произвольный код по SSH, не оставляя следов в логах sshd.
Всё началось в октябре 2021, когда некто под ником JiaT75 начал активно участвовать в развитии XZ, делать пул реквесты. Разумеется, мейнтенером проекта он не был. Через некоторое время появилось ещё два персонажа Jigar Kumar и Dennis Ens, которые также начали контрибьютить в проект. Через какое-то время в переписках они начали аккуратно давить на мейнтейнера проекта, что как будто он не справляется с нагрузкой, не успевает вовремя ревьюить пулл реквесты и что хорошо бы сделать JiaT75 ещё одним мейнтейнером. Так оно и случилось, JiaT75 стал мейнтейнером проекта XZ, а через некоторое время внедрил в него бекдор.
Вот что значит играть вдолгую :) Причём после релиза библиотеки с бекдором злоумышленники с левых аккаунтов стали писать меинтейнерам программ и дистрибутивов, мол, обновляйтесь.
Вскрылось всё это случайно. Один ну очень внимательный разработчик заметил, что XZ стало поджирать больше cpu, чем обычно. Он начал разбираться и обнаружил вредоносный код.
Такая невероятная история. Обязательно почитайте. Страшно представить, сколько подобных бекдоров мы ещё не знаем…
Больше деталей на opennet, в том числе разбор логики бекдора. Интересные детали ещё в канале Авва.
#security
Для тех кто пропустил детективную новость – бекдор в пакете архиватора XZ Utils, который повсеместно используется в Linux. Уязвимость предоставляет возможность выполнить произвольный код по SSH, не оставляя следов в логах sshd.
Всё началось в октябре 2021, когда некто под ником JiaT75 начал активно участвовать в развитии XZ, делать пул реквесты. Разумеется, мейнтенером проекта он не был. Через некоторое время появилось ещё два персонажа Jigar Kumar и Dennis Ens, которые также начали контрибьютить в проект. Через какое-то время в переписках они начали аккуратно давить на мейнтейнера проекта, что как будто он не справляется с нагрузкой, не успевает вовремя ревьюить пулл реквесты и что хорошо бы сделать JiaT75 ещё одним мейнтейнером. Так оно и случилось, JiaT75 стал мейнтейнером проекта XZ, а через некоторое время внедрил в него бекдор.
Вот что значит играть вдолгую :) Причём после релиза библиотеки с бекдором злоумышленники с левых аккаунтов стали писать меинтейнерам программ и дистрибутивов, мол, обновляйтесь.
Вскрылось всё это случайно. Один ну очень внимательный разработчик заметил, что XZ стало поджирать больше cpu, чем обычно. Он начал разбираться и обнаружил вредоносный код.
Такая невероятная история. Обязательно почитайте. Страшно представить, сколько подобных бекдоров мы ещё не знаем…
Больше деталей на opennet, в том числе разбор логики бекдора. Интересные детали ещё в канале Авва.
#security
The Verge
How one volunteer stopped a backdoor from exposing Linux systems worldwide
An off-the-clock Microsoft developer got suspicious while doing some micro-benchmarking.
The ultimate docker compose cheat sheet
Хорошая статья, охватывающая основные аспекты docker compose. Автор начинает с базовых концепций, но будет полезна даже тем, кто хорошо знаком с компоузом.
Из интересного:
– параметр, позволяющий рестартить сервис, если он завалился
– как одному сервису дождаться запуска другого сервиса с использованием определенных условий. Бывает полезно, когда веб-сервис дожидается старта базы данных
– как задавать healthcheck сервисов с различными параметрами
– также автор разжёвывает тему volumes и networks
У нас был отдельный пост с практическими советами по докеру.
#skills #docker
Хорошая статья, охватывающая основные аспекты docker compose. Автор начинает с базовых концепций, но будет полезна даже тем, кто хорошо знаком с компоузом.
Из интересного:
– параметр, позволяющий рестартить сервис, если он завалился
– как одному сервису дождаться запуска другого сервиса с использованием определенных условий. Бывает полезно, когда веб-сервис дожидается старта базы данных
– как задавать healthcheck сервисов с различными параметрами
– также автор разжёвывает тему volumes и networks
У нас был отдельный пост с практическими советами по докеру.
#skills #docker
DevOps Cycle
The Ultimate Docker Compose Cheat Sheet - DevOps Cycle
Get your Docker Compose Cheat Sheet as PDF or PNG. In this article, you learn how to manage Multi Container Apps with Docker Compose.