Может и для компаний такой алгоритм сделать, чтобы видеть тех кто на аутсорс проекты отдаёт.
Недавно видел работу по восстановлению фото человека по записи его голоса.
Определение страны по исходному коду — это будет что-то новенькое.
Хотя code convention сильно мешают, но отдельные регионы могут иметь отпечатки своих «школ» программирования, включая специфический плохой английский в названиях методов/классов/переменных и в комментариях.
Честно говоря, никакой конкретики. Даже на их сайте.
Диагностика каких онкозаболеваний? 95% точности при какой чувствительности? Как выглядят AUC для разных патологий? Были ли проведены реальные клинические испытания и доказано повышение эффективности работы рентгенологов? Это же не таблица результатов на Kaggle, а позиционируется как «AI-система диагностики онкологических заболеваний».
Вот интересная статья на тему разницы между точностью системы диагностики и клиническими результатами внедрения от австралийского рентгенолога и автора блога с серией статей про достижения и проблемы в ИИ в современной медицине. Суть в том, что система, которая должна была повысить качество работы рентгенологов в США, по факту ее понизила. При этом обошлась в миллиарды налогоплательщикам.
Там же есть статьи и на тему неадекватности оценки таких систем одной точностью.
По поводу ускорения и спецэффектов, сразу вспомнилось реалити-шоу Невероятное космическое надувательство. Особенно момент, когда «счастливчиков» выводили на орбиту без перегрузок, а в «космосе» убедили в том, что гравитация искусственная.
Были в гостях у знакомой пары в Неаполе. Девушка немного говорит на английском. Познакомила нас со своим парнем — программистом. Думаю, вот удача: расспрошу что тут да как. Оказалось, он английский не знает от слова вообще. С трудом узнал у него на чем он программирует, после чего разговор иссяк. Никогда не думал, что возможно стать программистом совсем без знания английского.
git-flow это «один из» возможных флоу и не является панацеей для всех.
Я отвечал на вопрос, в чем проблема мержей без рибейзов. И это — нечитаемая история.
А рибейз — единственный способ решения данной проблемы.
Git-flow, к сожалению, ее не решает, а только усугубляет: www.endoflineblog.com/gitflow-considered-harmful
Каждый сам выбирает, что для него важней. Плюс git-а в том, что он дает возможность выбора.
Кстати, у нас в одном проекте использовался git flow (не утилита, а концепция), но при этом никто не мешал нам делать рибейзы перед мержем.
Это не призыв к отмене чтения документации.
Коммент был скорее о том, что документация git не описывает как в данном проекте он должен быть использован. Поэтому нужно до всех донести стратегию создания и мержа веток для фич, хотфиксов и т.п.
А для особо одаренных — детально описать все пошагово.
По опыту, далеко не все сразу понимают парадигму работы с несколькими форками после SVN.
Еще одна проблема git — в нем можно одно и то же сделать по-разному. И в команде все начинают делать по-своему, что при отсутствии опыта часто приводит к проблемам.
>если в команде новичков есть доступ в master, то у них по определению не было более опытных товарищей.
В git нельзя ограничить доступ на одну ветку. Поэтому, если в проекте не используются личные форки и ограниченный доступ в основной репозиторий (что делает основные процессы намного сложней и используется далеко не везде), такой доступ будет у всех, включая новичков.
По опыту, при миграции команды на git (наверное, и на другие СКВ тоже), нужно начать с документа по git-флоу на основные рабочие процессы: создание ветки для фичи, обновление ее к мастеру, мерж, решение конфликтов, перенос изменений в другую ветку и т.п.
В котором описать необходимые команды, их результат и основные сценарии ошибок. Отдельно описать best practice для вашего проекта, например почему hard reset на мастер делать не нужно, или нужно ли делать рибейз перед мержем в общую ветку.
Без опыта и четких инструкций команда новичков (особенно с доступом в мастер) может запороть мастер и подкинуть работы на пару дней более опытным товарищам.
Я наоборот начинал с командной строки. Ну, кроме диффа/коммита. А потом понемногу начинал пользоваться остальными командами из UI, когда убедился что они делают то что нужно. Мне наоборот спокойней, когда я понимаю, что происходит под капотом, а не «VCS/Update», который непонятно что сделает с веткой. Да и поддержка всех нужных функций в IDEA появилась далеко не сразу (типа pull --rebase, rebase -i со squash, pull --no-ff и т.п.).
В проекте с 10+ разработчиков «бриллиант» превращается в огромное «макраме», в котором сложно разобрать, что произойдет при откате мержа, или какие новые фичи попали в текущий тег, например. Т.е. визуальный граф становится практически бесполезным как инструмент. Хороший пример
А разработчик просто каждый раз будет испытывать боль и либо потеряет иностранного клиента, либо поменяет свое географическое положение на то, которое не является аннексированной территорией и не попадает под санкции (что основная масса более дальновидных и сделала еще в 2014). И еще один денежный ручеек для государства-агрессора перекроется. В этом и есть смысл экономических санкций.
Это лучше скажите иностранному клиенту, с которым они раньше общались через тот самый Slack.
Про Яндекс.* и Чебурашку знают только на внутреннем рынке и никто извне в здравом уме не будет использовать по причине тотального контроля спецслужбами.
Реквестим в Atlassian фичу для Bitbucket: анонимные пулл-реквесты, в которых дифф виден только автору, а для остальных доступна ТОЛЬКО кнопка «Approve».
Недавно видел работу по восстановлению фото человека по записи его голоса.
Определение страны по исходному коду — это будет что-то новенькое.
Хотя code convention сильно мешают, но отдельные регионы могут иметь отпечатки своих «школ» программирования, включая специфический плохой английский в названиях методов/классов/переменных и в комментариях.
Диагностика каких онкозаболеваний? 95% точности при какой чувствительности? Как выглядят AUC для разных патологий? Были ли проведены реальные клинические испытания и доказано повышение эффективности работы рентгенологов? Это же не таблица результатов на Kaggle, а позиционируется как «AI-система диагностики онкологических заболеваний».
Вот интересная статья на тему разницы между точностью системы диагностики и клиническими результатами внедрения от австралийского рентгенолога и автора блога с серией статей про достижения и проблемы в ИИ в современной медицине. Суть в том, что система, которая должна была повысить качество работы рентгенологов в США, по факту ее понизила. При этом обошлась в миллиарды налогоплательщикам.
Там же есть статьи и на тему неадекватности оценки таких систем одной точностью.
Я отвечал на вопрос, в чем проблема мержей без рибейзов. И это — нечитаемая история.
А рибейз — единственный способ решения данной проблемы.
Git-flow, к сожалению, ее не решает, а только усугубляет:
www.endoflineblog.com/gitflow-considered-harmful
Каждый сам выбирает, что для него важней. Плюс git-а в том, что он дает возможность выбора.
Кстати, у нас в одном проекте использовался git flow (не утилита, а концепция), но при этом никто не мешал нам делать рибейзы перед мержем.
Коммент был скорее о том, что документация git не описывает как в данном проекте он должен быть использован. Поэтому нужно до всех донести стратегию создания и мержа веток для фич, хотфиксов и т.п.
А для особо одаренных — детально описать все пошагово.
По опыту, далеко не все сразу понимают парадигму работы с несколькими форками после SVN.
Еще одна проблема git — в нем можно одно и то же сделать по-разному. И в команде все начинают делать по-своему, что при отсутствии опыта часто приводит к проблемам.
>если в команде новичков есть доступ в master, то у них по определению не было более опытных товарищей.
В git нельзя ограничить доступ на одну ветку. Поэтому, если в проекте не используются личные форки и ограниченный доступ в основной репозиторий (что делает основные процессы намного сложней и используется далеко не везде), такой доступ будет у всех, включая новичков.
В котором описать необходимые команды, их результат и основные сценарии ошибок. Отдельно описать best practice для вашего проекта, например почему hard reset на мастер делать не нужно, или нужно ли делать рибейз перед мержем в общую ветку.
Без опыта и четких инструкций команда новичков (особенно с доступом в мастер) может запороть мастер и подкинуть работы на пару дней более опытным товарищам.
Про Яндекс.* и Чебурашку знают только на внутреннем рынке и никто извне в здравом уме не будет использовать по причине тотального контроля спецслужбами.