Благодаря дженерикам в Go наконец-то можно будет написать универсальную для всех типов (ну, почти) функцию поиска элемента в списке. Что-то типа такого:
Мелочь, а приятно
func find[T comparable](s []T, w T) int {
for i, v := range s {
if v == w {
return i
}
}
return -1
}Мелочь, а приятно
👀1
Ночью не спалось что-то, в голову лезли мысли про тестирование.
Вот есть, например, код (допустим микросервис с http-эндпоинтами), и к нему написаны какие-то тесты. Уверен ли я, что тестов достаточно? Могу ли я серьёзно отрефакторить код и быть уверенным, что ничего не поломал?
Если честно, почти всегда паранойа заставляет быть готовым к любым неожиданностям. Тестов всегда маловато.
Но с другой стороны, покрывать всё тестами на 100.0% (например, анализируя через мутационное тестирование) - слишком дорого. Действительно, зачем покрывать ветки кода, где, например, в случае ошибки при отправке тела ответа сервера, в лог пишется какой-то текст. Ну пишется и пишется, что там тестировать. Особенно, если это некритичная часть системы.
В итоге подумалось, что неплохо было бы иметь такую штуку. Собирать каким-то магическим образом статистику с прода, какие участки кода чаще всего используются. И их потом покрывать тестами с особой тщательностью. Если частые участки покрыты, то можно рефакторить без проблем. Т.е. даже когда что-то пойдет не так - это пойдет не так в малоиспользуемом месте.
А еще лучше каждому эндпоинту назначить сумму в деньгах, а потом важность строчек кода анализировать в рублях в час. И можно сравнить затраты на программиста на написание тестов с затратами на потери при некорректной работе данной строки кода.
Еще лучше, чтобы такая система сразу автоматически выдавала на блюдечеке дорогие места, не покрытые тестами.
Таким образом, всякая херня не будет тестироватсья никогда - и слава богу. А сверхважные денежные куски кода будут покрыты тестами на 146%
Вот такие у меня эротические фантазии по ночам
Вот есть, например, код (допустим микросервис с http-эндпоинтами), и к нему написаны какие-то тесты. Уверен ли я, что тестов достаточно? Могу ли я серьёзно отрефакторить код и быть уверенным, что ничего не поломал?
Если честно, почти всегда паранойа заставляет быть готовым к любым неожиданностям. Тестов всегда маловато.
Но с другой стороны, покрывать всё тестами на 100.0% (например, анализируя через мутационное тестирование) - слишком дорого. Действительно, зачем покрывать ветки кода, где, например, в случае ошибки при отправке тела ответа сервера, в лог пишется какой-то текст. Ну пишется и пишется, что там тестировать. Особенно, если это некритичная часть системы.
В итоге подумалось, что неплохо было бы иметь такую штуку. Собирать каким-то магическим образом статистику с прода, какие участки кода чаще всего используются. И их потом покрывать тестами с особой тщательностью. Если частые участки покрыты, то можно рефакторить без проблем. Т.е. даже когда что-то пойдет не так - это пойдет не так в малоиспользуемом месте.
А еще лучше каждому эндпоинту назначить сумму в деньгах, а потом важность строчек кода анализировать в рублях в час. И можно сравнить затраты на программиста на написание тестов с затратами на потери при некорректной работе данной строки кода.
Еще лучше, чтобы такая система сразу автоматически выдавала на блюдечеке дорогие места, не покрытые тестами.
Таким образом, всякая херня не будет тестироватсья никогда - и слава богу. А сверхважные денежные куски кода будут покрыты тестами на 146%
Вот такие у меня эротические фантазии по ночам
👀1
Forwarded from Тимлид Очевидность | Евгений Антонов
Байкшеддинг
Если вам кажется, что частенько на совещаниях излишне долго обсуждаются незначительные мелочи, а по-настоящему важные вещи быстро пропускаются, то вам не кажется. У этого есть даже название.
«Эффект велосипедного сарая» — bike-shed.
«Эффект велосипедного сарая» или «закон тривиальности Паркинсона» был сформулирован Сирилом Норткотом Паркинсоном в 1957 году. Он привел в пример совещание на атомной электростанции, на котором большую часть времени участники потратили на обсуждение мелких и простых для понимания вопросов, таких как цвет велосипедного сарая, а не конструкции самой электростанции. Как объяснил инженер Карл Фогель, «время, потраченное на обсуждение пункта, обратно пропорционально его сложности и важности».
Почему так происходит?
Дискутировать о чем-то сложном и принимать ответственные решения – это большая когнитивная нагрузка, плюс не у всех есть для этого нужные компетенции.
Зато по любым тривиальным вопросам у каждого точно есть своё важное мнение, которое обязательно надо высказать. Да и обсуждать такое проще, а ответственности за всё это меньше.
Вот и получается, что люди интуитивно или по своей лени идут по более простому пути. Хоть это и контрпродуктивно
Что с этим делать?
Знать об этом явлении. Всегда об этом помнить. Стараться вовремя возвращать на путь важных и продуктивных обсуждений себя и помогать вернуться другим.
Человеческий фактор настолько неискореним, что лично я не вижу какой-то серебряной пули или волшебного слова, который раз и навсегда вылечит такую проблему.
Однако сознательность и дисциплина помогут сначала конкретному человеку, а педагогика и просвещение со стороны этого человека помогут всему коллективу.
Итог
Больше концентрируйтесь на важном. Возвращайте себя и своих коллег к обсуждению важного, когда они отвлеклись на обмусоливание незначительных мелочей.
Покажите этот пост коллегам, которые страдают байкшеддингом.
Если вам кажется, что частенько на совещаниях излишне долго обсуждаются незначительные мелочи, а по-настоящему важные вещи быстро пропускаются, то вам не кажется. У этого есть даже название.
«Эффект велосипедного сарая» — bike-shed.
«Эффект велосипедного сарая» или «закон тривиальности Паркинсона» был сформулирован Сирилом Норткотом Паркинсоном в 1957 году. Он привел в пример совещание на атомной электростанции, на котором большую часть времени участники потратили на обсуждение мелких и простых для понимания вопросов, таких как цвет велосипедного сарая, а не конструкции самой электростанции. Как объяснил инженер Карл Фогель, «время, потраченное на обсуждение пункта, обратно пропорционально его сложности и важности».
Почему так происходит?
Дискутировать о чем-то сложном и принимать ответственные решения – это большая когнитивная нагрузка, плюс не у всех есть для этого нужные компетенции.
Зато по любым тривиальным вопросам у каждого точно есть своё важное мнение, которое обязательно надо высказать. Да и обсуждать такое проще, а ответственности за всё это меньше.
Вот и получается, что люди интуитивно или по своей лени идут по более простому пути. Хоть это и контрпродуктивно
Что с этим делать?
Знать об этом явлении. Всегда об этом помнить. Стараться вовремя возвращать на путь важных и продуктивных обсуждений себя и помогать вернуться другим.
Человеческий фактор настолько неискореним, что лично я не вижу какой-то серебряной пули или волшебного слова, который раз и навсегда вылечит такую проблему.
Однако сознательность и дисциплина помогут сначала конкретному человеку, а педагогика и просвещение со стороны этого человека помогут всему коллективу.
Итог
Больше концентрируйтесь на важном. Возвращайте себя и своих коллег к обсуждению важного, когда они отвлеклись на обмусоливание незначительных мелочей.
Покажите этот пост коллегам, которые страдают байкшеддингом.
Полное (даже слишком) описание фич Postgresql 14.
Никакой революции нет, но возможно какие-то отдельные вещи, связанные например с партициями или рекурсивными CTE вам могут пригодиться
https://m.habr.com/ru/company/postgrespro/blog/550632/
Никакой революции нет, но возможно какие-то отдельные вещи, связанные например с партициями или рекурсивными CTE вам могут пригодиться
https://m.habr.com/ru/company/postgrespro/blog/550632/
Хабр
PostgreSQL 14: Часть 5 или «весенние заморозки» (Коммитфест 2021-03)
8 апреля 2021 г. в 15:00 по московскому времени закончился мартовский коммитфест, а вместе с ним и прием изменений в PostgreSQL 14. Напомню, что всё самое интересное о первых четырех...
Кратко о канбан-методе, сумбурный набор тезисов.
1) Канбан-метод и канбан, который в Тойоте - это два разных канбана.
2) Канбан-метод, в отличие от скрама, не является набором конкретных жестких правил и инструментов. Это скорее набор принципов и рекомендуемых практик
3) Один из главных принципов - надо начать с того, что есть, и эволюционно развивать, а не перестраивать всё сразу целиком. И одна из важнейших практик с этим связанная - для начала надо визуализировать то, что есть сейчас.
Очень много примеров, когда удачное отображение происходящих процессов на канбан-доске сразу сходу выявляет большую проблему и приносит немедленный профит. Ключевой пункт здесь - надо отрисовывать доску как оно есть на самом деле.
Например, если перед выкаткой кода надо получить апрув Иван Иваныча, даже если это просто кивок головой, то Иван Иваныч должен существовать в виде отдельной колонки на канбан-доске. И возможно перед ним будет видна большая очередь задач.
4) обычная программистская задача, если посмотреть на нее от момента взятия в работу до попадания на прод, больше ждет, чем по ней реально идут работы. Иногда в 10-20 раз. Это ожидание код ревью, деплоя, уточнений у коллег, прерывания на выполнение более важных задач и тд.
5) поэтому вторая обязательная практика - это ограничение количества задач, одновременно взятых в работу (wip-лимит). У десяти программистов всего десять голов, они не могут делать 100 задач одновременно. Стоит поставить разумный лимит на количество одновременно выполняемых работ, это существено уменьшит lead time, существенно увеличит предсказуемость поставки и даже улучшит самочувствие разработчиков и лидов. Программисты не будут переключаться с задачи на задачу, лид будет полностью понимать, что происходит в его отделе.
6) Когда количество задач ограничено, придется построить процесс, который позволяет понять, какую задачу брать следующей, когда освободилось место. Заказчики (product-менеджеры) должны между собой договориться, какая задача сейчас важнее.
7) Так как обычно задача больше ждет чего-то, чем программируется, важнее отслеживать, кто кого блокирует, чем кто быстрее программирует. Поэтому стоит делать ежедневный митинг на 5-10 минут для выявления блокеров.
8) Визуализация может быть на нескольких уровнях. На одной доске продуктовые задачи, приносящие ценность, на других досках отдельные задачи в каждой из тех команд.
И там, и там должны быть свои WIP-лимиты.
9) WIP- лимиты вообще не зависят от размера задач. Это количество одновременно разрабатываемых задач, только и всего. Не путать со скрамом и списком задач на спринт.
10) идеально использовать "вытягивание". Т.е. только когда освободилось место (задач в работе меньше, чем WIP-лимит), брать новую задачу у продактов. Но в реальности продакты не могут работать "по вызову" и собираются время от времени, чтобы сформировать небольшой список актуальных задач, из которых разработчики будут брать задачи, когда освободятся руки. Размер этого буфера зависит лишь от частоты, с которой продакты собираются и изменчивости рынка
1) Канбан-метод и канбан, который в Тойоте - это два разных канбана.
2) Канбан-метод, в отличие от скрама, не является набором конкретных жестких правил и инструментов. Это скорее набор принципов и рекомендуемых практик
3) Один из главных принципов - надо начать с того, что есть, и эволюционно развивать, а не перестраивать всё сразу целиком. И одна из важнейших практик с этим связанная - для начала надо визуализировать то, что есть сейчас.
Очень много примеров, когда удачное отображение происходящих процессов на канбан-доске сразу сходу выявляет большую проблему и приносит немедленный профит. Ключевой пункт здесь - надо отрисовывать доску как оно есть на самом деле.
Например, если перед выкаткой кода надо получить апрув Иван Иваныча, даже если это просто кивок головой, то Иван Иваныч должен существовать в виде отдельной колонки на канбан-доске. И возможно перед ним будет видна большая очередь задач.
4) обычная программистская задача, если посмотреть на нее от момента взятия в работу до попадания на прод, больше ждет, чем по ней реально идут работы. Иногда в 10-20 раз. Это ожидание код ревью, деплоя, уточнений у коллег, прерывания на выполнение более важных задач и тд.
5) поэтому вторая обязательная практика - это ограничение количества задач, одновременно взятых в работу (wip-лимит). У десяти программистов всего десять голов, они не могут делать 100 задач одновременно. Стоит поставить разумный лимит на количество одновременно выполняемых работ, это существено уменьшит lead time, существенно увеличит предсказуемость поставки и даже улучшит самочувствие разработчиков и лидов. Программисты не будут переключаться с задачи на задачу, лид будет полностью понимать, что происходит в его отделе.
6) Когда количество задач ограничено, придется построить процесс, который позволяет понять, какую задачу брать следующей, когда освободилось место. Заказчики (product-менеджеры) должны между собой договориться, какая задача сейчас важнее.
7) Так как обычно задача больше ждет чего-то, чем программируется, важнее отслеживать, кто кого блокирует, чем кто быстрее программирует. Поэтому стоит делать ежедневный митинг на 5-10 минут для выявления блокеров.
8) Визуализация может быть на нескольких уровнях. На одной доске продуктовые задачи, приносящие ценность, на других досках отдельные задачи в каждой из тех команд.
И там, и там должны быть свои WIP-лимиты.
9) WIP- лимиты вообще не зависят от размера задач. Это количество одновременно разрабатываемых задач, только и всего. Не путать со скрамом и списком задач на спринт.
10) идеально использовать "вытягивание". Т.е. только когда освободилось место (задач в работе меньше, чем WIP-лимит), брать новую задачу у продактов. Но в реальности продакты не могут работать "по вызову" и собираются время от времени, чтобы сформировать небольшой список актуальных задач, из которых разработчики будут брать задачи, когда освободятся руки. Размер этого буфера зависит лишь от частоты, с которой продакты собираются и изменчивости рынка
Написал тред-ответ на твит, что микросервисный подход - говно.
https://twitter.com/AntonOkolelov/status/1385528227687510018
https://twitter.com/AntonOkolelov/status/1385528227687510018
Twitter
Anton Okolelov
Не согласен. Ща запилю тредик. 1) Монолит со временем превращается в сраное говно. Всегда. Срезанные углы перед дедлайном (говнокод), устаревающий подход к разработке, устаревающий фреймворк, перегруженная база, в которую ничего не влезает и т.д. Микросервис…
Вопросы для собеседования (php). Хорошие или плохие, собраны с реальных интервьюеров, поэтому стоит посмотреть
https://techrocks.ru/2021/04/18/250-php-job-interview-questions/?utm_source=telegram.me&utm_medium=social&utm_campaign=250+-voprosov-s-sobesedovaniy-po-php.-tr&utm_content=50169982
https://techrocks.ru/2021/04/18/250-php-job-interview-questions/?utm_source=telegram.me&utm_medium=social&utm_campaign=250+-voprosov-s-sobesedovaniy-po-php.-tr&utm_content=50169982
Питер: speed-dating для айтишников. https://itsd.timepad.ru/event/1627673/
Forwarded from Проветримся!
я обычно не перепащиваю свои же посты, но тут дело полезное
Собрал отличный квест на выходные.
Идём по ссылке. Читаем, как предлагается регулировать просветительскую деятельность. Убеждаемся, что в текущей редакции данный акт противоречит конституции Российской Федерации (29. 4).
"Каждый имеет право свободно искать, получать, передавать, производить и распространять информацию любым законным способом."
Логинимся через Госуслуги.
Нажимаем дизлайк.
Вносим предложение:
Пункт 4 данного акта в текущем виде противоречит ст. 29 Конституции РФ, предусматривающей право свободно делиться любой информацией, прямо не запрещённой Конституцией и федеральными законами.
Предлагаю дополнить пункт 4:
"Просветительская деятельность, осуществляемая вне образовательных, научных и культурных организаций, не требует заключения вышеозначенного договора и может осуществляться самим субъектом просветительской деятельности."
Спасибо.
Собрал отличный квест на выходные.
Идём по ссылке. Читаем, как предлагается регулировать просветительскую деятельность. Убеждаемся, что в текущей редакции данный акт противоречит конституции Российской Федерации (29. 4).
"Каждый имеет право свободно искать, получать, передавать, производить и распространять информацию любым законным способом."
Логинимся через Госуслуги.
Нажимаем дизлайк.
Вносим предложение:
Пункт 4 данного акта в текущем виде противоречит ст. 29 Конституции РФ, предусматривающей право свободно делиться любой информацией, прямо не запрещённой Конституцией и федеральными законами.
Предлагаю дополнить пункт 4:
"Просветительская деятельность, осуществляемая вне образовательных, научных и культурных организаций, не требует заключения вышеозначенного договора и может осуществляться самим субъектом просветительской деятельности."
Спасибо.
Дима Пацура (https://twitter.com/ovrweb) рассказал в эфире "Цинкового прода" про аналитическую платформу cube.js
https://youtube.com/watch?v=YcpYmPOTq98
https://youtube.com/watch?v=YcpYmPOTq98
Появились записи докладов с gopherCon Russia. Enjoy!
https://www.youtube.com/channel/UCq-OB01F8YnS-FJpeJRCvMQ/videos
https://www.youtube.com/channel/UCq-OB01F8YnS-FJpeJRCvMQ/videos
Рубрика ответов на нашумевшие твиты продолжается.
А вы стали бы убирать говно за бомжами вместо программирования, если бы вам платили в два раза больше?
Я - точно нет. Поэтому зп - точно не единственный фактор, хотя и экстремально важный.
https://mobile.twitter.com/AntonOkolelov/status/1389782725595435014
А вы стали бы убирать говно за бомжами вместо программирования, если бы вам платили в два раза больше?
Я - точно нет. Поэтому зп - точно не единственный фактор, хотя и экстремально важный.
https://mobile.twitter.com/AntonOkolelov/status/1389782725595435014
Twitter
Anton Okolelov
Хороший, эффективный наброс. Деньги, конечно, очень важны. Однако, не только они. Скажи, @fillpackart, ты стал бы вместо программирования убирать говно за бомжами, если бы тебе платили x2? :) Важны деньги, задачи, уважение, технологии, процессы и чтоб начальник…
Статья о том, что в Go не нужен крутой garbage collector как в Java, потому что у таких языков как Go гораздо меньше аллокаций в куче.
Статья интересная. От себя замечу, что некорректно вообще-то сравнивать Go и Java. И тем более Rust.
Go - для маленьких эффективных микросервисов, и упор на грамотное выделение памяти (а не на хитрожопый GC) оправдан.
Java - для ООП-монстров, набитых бизнес-логикой, возможно там нужен именно что крутой GC, и это норма.
Rust - для лютого байтоёбства, где нужно экономить каждый бит данных и такт процессора, даже ценой переусложнения кода. Для написания БД, например. В Расте вообще нет GC, точнее, где именно чистить память известно уже на этапе компиляции, в рантайме ничего колдовать не надо.
Все три подхода оправданы для своих целей.
Алсо мы тут поспорили в Фейсбуке, нормально ли на Java писать базы данных. Все знают, что есть куча примеров, те же Kafka и Elastic, написанные на этом языке. Однако честно скажу. Мне все же кажется, что при разработке Кафки наверняка пришлось заниматься лютейшим байтоёбством, выжимать максимум производительности и минимизировать память.
А ебать байты на java всё же в 100 раз сложнее, чем на системных языках, где это всё из коробки.
Поэтому если б я сейчас писал кафку, я бы точно выбрал какой-нибудь Раст.
Статья интересная. От себя замечу, что некорректно вообще-то сравнивать Go и Java. И тем более Rust.
Go - для маленьких эффективных микросервисов, и упор на грамотное выделение памяти (а не на хитрожопый GC) оправдан.
Java - для ООП-монстров, набитых бизнес-логикой, возможно там нужен именно что крутой GC, и это норма.
Rust - для лютого байтоёбства, где нужно экономить каждый бит данных и такт процессора, даже ценой переусложнения кода. Для написания БД, например. В Расте вообще нет GC, точнее, где именно чистить память известно уже на этапе компиляции, в рантайме ничего колдовать не надо.
Все три подхода оправданы для своих целей.
Алсо мы тут поспорили в Фейсбуке, нормально ли на Java писать базы данных. Все знают, что есть куча примеров, те же Kafka и Elastic, написанные на этом языке. Однако честно скажу. Мне все же кажется, что при разработке Кафки наверняка пришлось заниматься лютейшим байтоёбством, выжимать максимум производительности и минимизировать память.
А ебать байты на java всё же в 100 раз сложнее, чем на системных языках, где это всё из коробки.
Поэтому если б я сейчас писал кафку, я бы точно выбрал какой-нибудь Раст.
Отлично поговорили про Канбан-метод с Максимом Фроловым и Алексеем Пименовым
00:00 Приветствие, знакомимся с гостями
2:25 Что такое Канбан-метод и в чем его преимущество?
7:10 Система канбан в Toyota и канбан метод
19:20 WIP лимиты в компании
26:13 Как наложить канбан-метод на вотерфол?
29:09 Зачем что-то менять, если все и так хорошо работает?
36:03 Основные практики канбана
39:59 Нужны ли отдельные тапы и детализация?
41:45 Ограничение незавершённой работы
49:44 Как должен работать WIP
55:21 Upstream и Downstream
1:03:20 WSJF, где начинается скрам и заканчивается канбан?
1:16:56 Скрамбан
1:21:09 Какие рамки у скрамбана ?
1:29:50 Что значит «гибкая методология», и относится ли к ней скрам?
1:34:14 Про классы обслуживания и приоритетность задач
1:38:35 Улучшение процессов
1:42:23 Первое правило внедрение канбан-метода: никто не должен знать про внедрение канбан-метода
1:50:30 Канбан - это про кайдзен? Зачем продавать канбан? (про правильное внедрение)
1:54:13 Мотивация команды, эффективность потока и проблемы скрама
2:05:44 В какой методологии мотивировать проще?
2:08:11 Инструменты для Канбан
2:18:12 Шарманим
https://www.youtube.com/watch?v=9Ms6tx2Sq-4
00:00 Приветствие, знакомимся с гостями
2:25 Что такое Канбан-метод и в чем его преимущество?
7:10 Система канбан в Toyota и канбан метод
19:20 WIP лимиты в компании
26:13 Как наложить канбан-метод на вотерфол?
29:09 Зачем что-то менять, если все и так хорошо работает?
36:03 Основные практики канбана
39:59 Нужны ли отдельные тапы и детализация?
41:45 Ограничение незавершённой работы
49:44 Как должен работать WIP
55:21 Upstream и Downstream
1:03:20 WSJF, где начинается скрам и заканчивается канбан?
1:16:56 Скрамбан
1:21:09 Какие рамки у скрамбана ?
1:29:50 Что значит «гибкая методология», и относится ли к ней скрам?
1:34:14 Про классы обслуживания и приоритетность задач
1:38:35 Улучшение процессов
1:42:23 Первое правило внедрение канбан-метода: никто не должен знать про внедрение канбан-метода
1:50:30 Канбан - это про кайдзен? Зачем продавать канбан? (про правильное внедрение)
1:54:13 Мотивация команды, эффективность потока и проблемы скрама
2:05:44 В какой методологии мотивировать проще?
2:08:11 Инструменты для Канбан
2:18:12 Шарманим
https://www.youtube.com/watch?v=9Ms6tx2Sq-4
YouTube
#112 Говорим о канбан-методе с Максимом Фроловым и Алексеем Пименовым
Мужики затёрли про канбан
00:00 Приветствие, знакомимся с гостями
2:25 Что такое Канбан-метод и в чем его преимущество?
7:10 Система канбан в Toyota и канбан метод
19:20 WIP лимиты в компании
26:13 Как наложить канбан-метод на вотерфол?
29:09 Зачем что-то…
00:00 Приветствие, знакомимся с гостями
2:25 Что такое Канбан-метод и в чем его преимущество?
7:10 Система канбан в Toyota и канбан метод
19:20 WIP лимиты в компании
26:13 Как наложить канбан-метод на вотерфол?
29:09 Зачем что-то…
Forwarded from OpenNews
Демонстрация атаки на редакторы кода, приводящей к утечке файлов при открытии исходных текстов
Продемонстрирован метод атаки на редактор кода VSCode, позволяющий передать произвольные системные файлы при открытии в редакторе специально оформленного исходного кода. В предложенной демонстрации при открытии кода на языке Rust, в котором используется процедурный макрос, выполняется установка соединения с хостом 127.0.0.1:8080 и отправка содержимого файла "~/.ssh/id_rsa" с SSH-ключами пользователя.
Продемонстрирован метод атаки на редактор кода VSCode, позволяющий передать произвольные системные файлы при открытии в редакторе специально оформленного исходного кода. В предложенной демонстрации при открытии кода на языке Rust, в котором используется процедурный макрос, выполняется установка соединения с хостом 127.0.0.1:8080 и отправка содержимого файла "~/.ssh/id_rsa" с SSH-ключами пользователя.