Так пусть люди сами и контролируют децентрализованные сети. А там большинство решит, исходя из своей морали, что в таких сетях приемлемо, а что нет. Как минимум получится социальный эксперимент.
Волноваться не стоит: даже в случае блокировки у тебя остается твой копия репозитория, она полностью идентична потерянной.
Для продукта компании в любом случае разворачивают gitlab на своем хостинге, для полного контроля за кодом.
Единственная потеря: русские разработчики не смогут вносить вклад в развитие человечества, и человечество потеряло доступ к результатам их труда, которые опять же были сделаны в интересах всего человечества.
Единственная странность - почему будущим человечества управляет узкая группа лиц в своих интересах, а не сообщество в общих интересах. Полагаю на это должна быть соответствующая реакция сообщества: опенсорс построен на немного других идеях и преследует немного другие цели, и такое поведение не приемлет в принципе.
Как же замечательно, что Линус задумал git именно децентрализованным: даже полная и внезапная блокировка центрального хранилища не приводит к потере результатов нескольких лет труда. И ни корпорации, ни политики на это повлиять не могут, как бы им этого не хотелось.
Побольше бы таких технологий в нашей жизни, устойчивых к водоворотам политики.
Думаю тут кардинальной разницы нет: по конструкции нет больших отличий от обычного движка, значит и усилия примерно одинаковые, а 500кг что тут что там через редуктор или рычаг можно получить, проблем прикрутить редуктор или рычаг к линейному приводу нет.
Больше волнует прочность штока - он же тут сборный, из дорогих магнитов. Возможно лучше взять что-то более прочное, типа стали или магнитного сплава, и перемагнитить зонально.
На промышленных станках обычно ставят цифровые линейки микронной точности на любую длину, с защитой от масла и пыли, для УЦИ. Пару лет назад одна ось стоила около 6к, т.е. доступно даже для любителя, ну а как сейчас хз. Самое главное - абсолютная точность и никаких велосипедов. Полностью закрывает проблему с точностью и координатами.
И самое главное: найдите людей, которые способны в анализ и оптимизацию на алгоритмическом уровне.
Пример из практики: тяжелые запросы рекомендаций в БД с множеством условий и проверкой остатков, выполняются суммарно около 6 секунд на 3 запроса, это много - покупатели уходят не дождавшись ответа, минус продажи.
За несколько лет опытной командой разработки было сделано несколько попыток его оптимизации. Ни к чему не пришли, потому что запрос максимально оптимален в классическом понимании. Как показала практика, так оно и есть.
Проблема пришла в виде мелкой просьбы, в стиле "Тут долго работает, если можно сделайте, нет - нет" при решении другой проблемы. Время оплачено независимо от результата, так что есть простор для экспериментов, а эксперименты это интересно.
День ушел на анализ запроса. Все индексы есть, путь с индексами тупиковый, отбрасываем.
Разбив запрос на части, выяснилось: почти все время уходит на проверку остатков, сделать с ними ничего нельзя, данных очень много прогоняется, время справедливое.
Кешировать запрос нельзя: остатки зависят от условий, а условия от остатков, плюс сортировка - запрос имеет смысл только целиком.
Полный тупик, понятно почему от решения отказывались несколько лет: его реально нет.
Эмоции, первый порыв отказаться, сославшись на практику команды, которая доказала что решения нет, нужно смириться с проблемой. Так можно, в своем праве, но решено взять еще несколько дней на обдумывание, проблема интересна своей очевидной нерешаемостью.
Через несколько дней фоновых размышлений нащупан вариант: что если отделить тяжелый запрос от легкого? Это лишает смысла результат, но решает основную часть проблемы: время. Решение очевидное, но из-за фокусировки на запросе приходит не сразу. Решение бесполезное: без учета остатков смысла в запросе нет. Но обретает смысл, добавив опыт и экспертизу: да, отдельные запросы сами по себе бессмысленны, но переводят проблему в другую плоскость - теперь у нас два запроса с разными свойствами, и по отдельности они отлично кешируются. Чтобы получить результат достаточно найти общие элементы двух множеств, а это элементарно. Бонусом возможность задавать любые условия: условия дешевые по времени, а тяжелые остатки повторно запрашивать больше не нужно.
Результат: 6с->2c. Уже неплохо, но хотелось бы хотя бы 0.6-0.8с, чтобы покупатель гарантированно дождался результата.
Ранее при анализе выяснилось что запроса с остатками всего 3, они уникальны, но так как остатки можно кешировать за один запрос, повторно их не запрашиваем - остается 3 быстрых запроса без остатков и 1 тяжелый запрос остатков, все кешировано.
Результат: 0.6с, это отличный результат, задача решена.
Но при анализе также выяснилось, что можно быстро внедрить еще две простейшие оптимизации.
Во-первых из-за особенностей каталога можно хранить только 10% остатков без потери функционала, что уменьшит и ускорит кеш. Чей бы и нет? Делаем.
Результат: 0.2с, это уже шикарный результат.
Во-вторых выяснилось что данные отлично поддаются сжатию, и тесты показали что сжатие длится буквально 0.01с, а значит можно еще уменьшить и ускорить кеши. Делаем.
Результат: 0.07с, без комментариев, это уже далеко за пределами желаемого.
Итог: на входе долгий запрос, целых 6 секунд, многолетний ущерб продажам, фактически нерешаемая классическими способами проблема. На выходе 0.07 секунды. Цена вопроса - несколько дней работы одного подходящего человека. Человека, которому интересно щелкать нерешаемые проблемы и погружаться в систему глубже, чем это обычно делает рядовой разработчик. Человека, который набрал опыт и экспертизу конкретно на сложных и непонятных случаях.
В данном случае проблема ко мне попала случайно, но что если приложить такие навыки конкретно к сложным случаям? Полагаю это отдельная специализация уже: из коллег на такое способны буквально единицы.
За всякие соцплюшки и новые тренды отвечает не разработка, а маркетинг и менеджмент, те кто заказывают вечеринку, а не те кто ее организует. Как собственно и за развитие продукта в целом. У разработки тут инициативы почти нет, у них есть только ТЗ на эти все плюшки. Такова потребность бизнеса, именно за удовлетворение этой потребности разработке платят.
Обычно этим занимаются самые опытные из команды, с достаточным уровнем экспертизы. Как минимум консультируют аналитика и валидируют ТЗ, чтобы там не было откровенной чуши. Но это есть далеко не везде. Впрочем даже ТЗ не везде есть, и это плохо.
Так и есть. Но минимально проработанное ТЗ при этом быть обязано, чтобы как минимум до исполнителя донести суть проблемы и желаемое решение, причем понятным для исполнителя языком, с учетом того что исполнители могут быть далеки от бизнеса и его потребностей. Это если команды совсем маленькие, и в роли архитектора сам исполнитель выступает. Но нужно понимать последствия: таких архитекторов в итоге на проекте 70%, все разного уровня, зачастую без понимания предметной области и проблем бизнеса, что там они напроектируют страшно представить, для этого и нужно централизованное управление, один ответственный за архитектуру или аналитику. Разгребать последствия через пару-тройку лет заказчику за свой счет предстоит, так что это не экономия на архитекторе и аналитиках, это попытка отсрочить расплату за ошибки.
Интересно на сколько окладов тянет такой список обязанностей: ученый, изобретатель, бухгалтер, спецагент, писатель, экономист. Цифра с длинной змейкой нулей вырисовывается.
Самое прикольное, когда не то что тотально парализовано все управляющее звено, а даже никто не представляет как оно вообще работает: ни документации, ни карт процессов, ничего, либо все это только для внутреннего пользования, а программист обломится, он же джедай. ТЗ тогда идут уровня "сделай что-то, не знаю что, не знаю как, но чтобы работало как я придумал, но как придумал не расскажу". Реальная проблема часто до конечного разработчика даже не доносится, теряясь в пути. Такое себе.
Интересное чтиво, есть что почерпнуть. Сам тоже пришел к чему то подобному.
Открыл для себя trello: концепция с досками и карточками. Этакий диспетчер задач в миниатюре, позволяет установить четкие правила работы, разгрузить мозг и сэкономить время и силы.
Прилетела просьба/задача - завел карточку, кинул в беклог. Завел несколько досок: что сделано, что делаю, что буду делать, и беклог. Выработал правила: не более 2-3 карточек в работе и "тронул - ходи": что попало в работу остается в работе до конца, никаких перетасовок, из "что делаю" карточки уходят только в "что сделал" и никак иначе.
Ограничение по количеству карточек в работе подбираешь по своим ощущениям. Эффективно погружаюсь в одну задачу, поэтому первый слот приоритетный. Монотонная работа выматывает, время от времени нужно переключаться - для этого и нужны 2 и 3 слоты. 3 слот наименее приоритетный и простаивает чаще других, он позволяет брать срочные задачи вне очереди, или какие-то фоновые задачи. Итоговая производительность между слотами раскладывается примерно как 50-75/25-50/5-25%. Это не 100%, но главное что это позволяет экономить силы и избежать блокировки конвеера - карточки неизбежно двигаются, что и требуется для успеха. Так что итоговая эффективность получается высокой: от быстро выжигающих спринтерских забегов и хаоса приходим к эффективным монотонным марафонам и порядку, не сгорая по пути.
Ограничение "тронул - ходи" это уже чисто принцип: без него получается слишком много переключений контекста, что эффективно съедает силы и время, сводя производительность к нулю, что приводит к психологическому дискомфорту и выгоранию. Без контроля сваливается слишком много "срочных" задач, которые на поверку оказываются абсолютно не важными, но ресурсов оценить это под нагрузкой просто нет, поэтому все не срочное остается в беклоге, а срочное уходит в "что буду делать". А то что уже в работе этот принцип подвинуть уже не дает: свободных слотов в "что делаю" нет, пока что-то оттуда не уйдет в "что сделано".
Между беклогом и "что буду делать" перемещения карточек свободные - это нормально, обстоятельства меняются, задачи меняют порядок очередности или отменяются.
Внутри доски "что делаю" перемещения карточек также свободные: это твой островок свободы - можешь переключаться между слотами как угодно, по настроению, но выбор у тебя ограничен только теми 3 задачами что есть в этих слотах, будь добр выбери что-то одно и займись этим.
Доска "что буду делать" нужна для сортировки задач по приоритету. Особых ограничений нет, но если там накапливается слишком много карточек, лишние лучше скинуть обратно в беклог, чтобы разгрузить мозг: поддерживать порядок больше десятка карточек сложно. По мере опустошения доски, накидываешь на неё карточек из беклога в любом порядке. Срочные задачи также попадают на неё, вытесняя остальные задачи в беклог.
Ну а доска "что сделал" служит для мотивации и отчетов: наглядно видно сколько много работы ты сделал, и всегда можешь четко сказать что именно было сделано, да и вообще что и в каком статусе. Сами движения карточек между досками также мотивируют: позволяют увидеть, что работа работается, все хорошо, ничего не простаивает, а значит ты крут.
Получается что-то вроде процессора в миниатюре: ты в роли исполнительного блока, работаешь только с небольшим объемом задач в виде слотов на доске "что делаю", задачи получаешь из кеша в виде доски "что буду делать" с сортировкой по приоритету, и занимаешься тем, что перекидываешь карточки из "что буду делать" в "что сделано" через "что делаю", попутно выполняя необходимую работу. Выстраивается некий конвеер, монотонно перемалывающий задачи. Правила и ограничения на нем защищают исполнителя от перегрузки.
На самом деле, из-за особенностей протоколов, проблема серьезнее, чем принято считать. К сожалению решения как правило принимает менеджмент, а он смотрит только на доступность в Москве, остальной мир не интересен. В итоге получается полный бред.
Я думаю не все так плохо. Просто в международные проекты не нужно допускать политику, и всё. Политику стоит оставить политикам. Большинству людей она не интересна.
Эм, это же классическая задача вывода листинга. Решается через отдельный интерфейс с пагинацией. Обычно он же поддерживает сортировку, в том числе по нескольким произвольным полям. Работает быстро как раз за счёт того, что лишние данные реально не запрашиваются, даже на уровне БД. Зачем тут велосипед - решительно непонятно.
Если судить по человеку, то всё намного проще: большая часть организма интеллектом вообще никак не контролируется. Те же автоматические реакции и рефлексы - сигналы замыкаются по короткому пути через отдельную простейшую нейронную сеть. Сам мозг по большей части гибридная машина, состоящая из множества отдельных специализированных нейронных сетей, решающих свои конкретные задачи. А интеллект в этой структуре занимает относительно небольшие мощности, сидит где-то глубоко, снимает высокоуровневые сигналы, работает с памятью, и вырабатывает высокоуровневые решения. Т.е. по большей части наш организм работает автоматически, гоняя по сетям огромные потоки данных, из которых до сознания доходит лишь капля информации.
Так что думаю для ИИ требуются не такие большие ресурсы, как для всего мозга. Основная задача: работа с памятью и обработка простейших высокоуровневых сигналов, заранее расжеванных и распознанных толстыми низкоуровневыми слоями (конкретно наш мозг ещё заранее из памяти вытаскивает нужные образы, предоставляя сознанию уже одни абстракции). На программном уровне все низкоуровневые слои можно даже не проектировать, заменив их заглушками. Остаётся только спроектировать ядро и интерфейсы к памяти, сигнальным и управляющим контурам.
Задача ещё сильнее упрощается, если не ориентироваться на человека, а просто пытаться создать специализированный ИИ, решающий узкий круг задач. В таком случае ядро схлопывается в чуть более сложный аналог правил из цепочек условий, но сдобренный нейросетями и работающий с памятью.
Но сам по себе ИИ без контроля малоэффективен, поэтому сверху нужен какой-нибудь ещё более простой контрольный контур, задача которого сводится к выработке обратной связи на решения основного ИИ, чтобы ИИ развивался в требуемую сторону. Традиционные нейросетки принято обучать заранее, с ИИ так не получится, он должен быть гибким, и уметь подстраиваться под ситуацию, меняться.
И в конце концов мы приходим к тому, что основные компоненты ИИ - это выработанные на основе опыта правила и состояние памяти. Эти абстракции работают даже на нашем уровне: вся личность человека определяется его опытом и памятью, лиши человека памяти - лишишь его личности, внуши ложную память - получишь ложную личность, опыт отнять нельзя, а память можно. Думаю в случае развития программного ИИ или появления каких-либо ИИ-компаньонов, дампы памяти будут массово тиражироваться, и скорее всего появится возможность их сколь-либо осмысленно препарировать и изменять, обеспечивая обмен тематическими пакетами знаний.
Так пусть люди сами и контролируют децентрализованные сети. А там большинство решит, исходя из своей морали, что в таких сетях приемлемо, а что нет. Как минимум получится социальный эксперимент.
Волноваться не стоит: даже в случае блокировки у тебя остается твой копия репозитория, она полностью идентична потерянной.
Для продукта компании в любом случае разворачивают gitlab на своем хостинге, для полного контроля за кодом.
Единственная потеря: русские разработчики не смогут вносить вклад в развитие человечества, и человечество потеряло доступ к результатам их труда, которые опять же были сделаны в интересах всего человечества.
Единственная странность - почему будущим человечества управляет узкая группа лиц в своих интересах, а не сообщество в общих интересах. Полагаю на это должна быть соответствующая реакция сообщества: опенсорс построен на немного других идеях и преследует немного другие цели, и такое поведение не приемлет в принципе.
Как же замечательно, что Линус задумал git именно децентрализованным: даже полная и внезапная блокировка центрального хранилища не приводит к потере результатов нескольких лет труда. И ни корпорации, ни политики на это повлиять не могут, как бы им этого не хотелось.
Побольше бы таких технологий в нашей жизни, устойчивых к водоворотам политики.
На поезде да, но в остальных случаях в чем проблема поставить редуктор? Да, выглядеть он будет немного непривычно, но по сути принцип тот же.
Думаю тут кардинальной разницы нет: по конструкции нет больших отличий от обычного движка, значит и усилия примерно одинаковые, а 500кг что тут что там через редуктор или рычаг можно получить, проблем прикрутить редуктор или рычаг к линейному приводу нет.
Больше волнует прочность штока - он же тут сборный, из дорогих магнитов. Возможно лучше взять что-то более прочное, типа стали или магнитного сплава, и перемагнитить зонально.
На промышленных станках обычно ставят цифровые линейки микронной точности на любую длину, с защитой от масла и пыли, для УЦИ. Пару лет назад одна ось стоила около 6к, т.е. доступно даже для любителя, ну а как сейчас хз. Самое главное - абсолютная точность и никаких велосипедов. Полностью закрывает проблему с точностью и координатами.
Сейчас в принципе оно тоже доступно, гугл выдает например это: http://ooo-asteko.ru/tsifrovaya-lineyka-dlya-stanka/
И самое главное: найдите людей, которые способны в анализ и оптимизацию на алгоритмическом уровне.
Пример из практики: тяжелые запросы рекомендаций в БД с множеством условий и проверкой остатков, выполняются суммарно около 6 секунд на 3 запроса, это много - покупатели уходят не дождавшись ответа, минус продажи.
За несколько лет опытной командой разработки было сделано несколько попыток его оптимизации. Ни к чему не пришли, потому что запрос максимально оптимален в классическом понимании. Как показала практика, так оно и есть.
Проблема пришла в виде мелкой просьбы, в стиле "Тут долго работает, если можно сделайте, нет - нет" при решении другой проблемы. Время оплачено независимо от результата, так что есть простор для экспериментов, а эксперименты это интересно.
День ушел на анализ запроса. Все индексы есть, путь с индексами тупиковый, отбрасываем.
Разбив запрос на части, выяснилось: почти все время уходит на проверку остатков, сделать с ними ничего нельзя, данных очень много прогоняется, время справедливое.
Кешировать запрос нельзя: остатки зависят от условий, а условия от остатков, плюс сортировка - запрос имеет смысл только целиком.
Полный тупик, понятно почему от решения отказывались несколько лет: его реально нет.
Эмоции, первый порыв отказаться, сославшись на практику команды, которая доказала что решения нет, нужно смириться с проблемой. Так можно, в своем праве, но решено взять еще несколько дней на обдумывание, проблема интересна своей очевидной нерешаемостью.
Через несколько дней фоновых размышлений нащупан вариант: что если отделить тяжелый запрос от легкого? Это лишает смысла результат, но решает основную часть проблемы: время. Решение очевидное, но из-за фокусировки на запросе приходит не сразу. Решение бесполезное: без учета остатков смысла в запросе нет. Но обретает смысл, добавив опыт и экспертизу: да, отдельные запросы сами по себе бессмысленны, но переводят проблему в другую плоскость - теперь у нас два запроса с разными свойствами, и по отдельности они отлично кешируются. Чтобы получить результат достаточно найти общие элементы двух множеств, а это элементарно. Бонусом возможность задавать любые условия: условия дешевые по времени, а тяжелые остатки повторно запрашивать больше не нужно.
Результат: 6с->2c. Уже неплохо, но хотелось бы хотя бы 0.6-0.8с, чтобы покупатель гарантированно дождался результата.
Ранее при анализе выяснилось что запроса с остатками всего 3, они уникальны, но так как остатки можно кешировать за один запрос, повторно их не запрашиваем - остается 3 быстрых запроса без остатков и 1 тяжелый запрос остатков, все кешировано.
Результат: 0.6с, это отличный результат, задача решена.
Но при анализе также выяснилось, что можно быстро внедрить еще две простейшие оптимизации.
Во-первых из-за особенностей каталога можно хранить только 10% остатков без потери функционала, что уменьшит и ускорит кеш. Чей бы и нет? Делаем.
Результат: 0.2с, это уже шикарный результат.
Во-вторых выяснилось что данные отлично поддаются сжатию, и тесты показали что сжатие длится буквально 0.01с, а значит можно еще уменьшить и ускорить кеши. Делаем.
Результат: 0.07с, без комментариев, это уже далеко за пределами желаемого.
Итог: на входе долгий запрос, целых 6 секунд, многолетний ущерб продажам, фактически нерешаемая классическими способами проблема. На выходе 0.07 секунды. Цена вопроса - несколько дней работы одного подходящего человека. Человека, которому интересно щелкать нерешаемые проблемы и погружаться в систему глубже, чем это обычно делает рядовой разработчик. Человека, который набрал опыт и экспертизу конкретно на сложных и непонятных случаях.
В данном случае проблема ко мне попала случайно, но что если приложить такие навыки конкретно к сложным случаям? Полагаю это отдельная специализация уже: из коллег на такое способны буквально единицы.
За всякие соцплюшки и новые тренды отвечает не разработка, а маркетинг и менеджмент, те кто заказывают вечеринку, а не те кто ее организует. Как собственно и за развитие продукта в целом. У разработки тут инициативы почти нет, у них есть только ТЗ на эти все плюшки. Такова потребность бизнеса, именно за удовлетворение этой потребности разработке платят.
Обычно этим занимаются самые опытные из команды, с достаточным уровнем экспертизы. Как минимум консультируют аналитика и валидируют ТЗ, чтобы там не было откровенной чуши. Но это есть далеко не везде. Впрочем даже ТЗ не везде есть, и это плохо.
Это уже опыт. Но опыт стоит дорого - большинство задач решают джуны, они дешевле. Платить за опыт мало кто хочет.
Так и есть. Но минимально проработанное ТЗ при этом быть обязано, чтобы как минимум до исполнителя донести суть проблемы и желаемое решение, причем понятным для исполнителя языком, с учетом того что исполнители могут быть далеки от бизнеса и его потребностей. Это если команды совсем маленькие, и в роли архитектора сам исполнитель выступает. Но нужно понимать последствия: таких архитекторов в итоге на проекте 70%, все разного уровня, зачастую без понимания предметной области и проблем бизнеса, что там они напроектируют страшно представить, для этого и нужно централизованное управление, один ответственный за архитектуру или аналитику. Разгребать последствия через пару-тройку лет заказчику за свой счет предстоит, так что это не экономия на архитекторе и аналитиках, это попытка отсрочить расплату за ошибки.
Слышал что индус делает все тоже самое, а получает 10 мрот. Хороший вариант
Интересно на сколько окладов тянет такой список обязанностей: ученый, изобретатель, бухгалтер, спецагент, писатель, экономист. Цифра с длинной змейкой нулей вырисовывается.
Самое прикольное, когда не то что тотально парализовано все управляющее звено, а даже никто не представляет как оно вообще работает: ни документации, ни карт процессов, ничего, либо все это только для внутреннего пользования, а программист обломится, он же джедай. ТЗ тогда идут уровня "сделай что-то, не знаю что, не знаю как, но чтобы работало как я придумал, но как придумал не расскажу". Реальная проблема часто до конечного разработчика даже не доносится, теряясь в пути. Такое себе.
Интересное чтиво, есть что почерпнуть. Сам тоже пришел к чему то подобному.
Открыл для себя trello: концепция с досками и карточками. Этакий диспетчер задач в миниатюре, позволяет установить четкие правила работы, разгрузить мозг и сэкономить время и силы.
Прилетела просьба/задача - завел карточку, кинул в беклог. Завел несколько досок: что сделано, что делаю, что буду делать, и беклог. Выработал правила: не более 2-3 карточек в работе и "тронул - ходи": что попало в работу остается в работе до конца, никаких перетасовок, из "что делаю" карточки уходят только в "что сделал" и никак иначе.
Ограничение по количеству карточек в работе подбираешь по своим ощущениям. Эффективно погружаюсь в одну задачу, поэтому первый слот приоритетный. Монотонная работа выматывает, время от времени нужно переключаться - для этого и нужны 2 и 3 слоты. 3 слот наименее приоритетный и простаивает чаще других, он позволяет брать срочные задачи вне очереди, или какие-то фоновые задачи. Итоговая производительность между слотами раскладывается примерно как 50-75/25-50/5-25%. Это не 100%, но главное что это позволяет экономить силы и избежать блокировки конвеера - карточки неизбежно двигаются, что и требуется для успеха. Так что итоговая эффективность получается высокой: от быстро выжигающих спринтерских забегов и хаоса приходим к эффективным монотонным марафонам и порядку, не сгорая по пути.
Ограничение "тронул - ходи" это уже чисто принцип: без него получается слишком много переключений контекста, что эффективно съедает силы и время, сводя производительность к нулю, что приводит к психологическому дискомфорту и выгоранию. Без контроля сваливается слишком много "срочных" задач, которые на поверку оказываются абсолютно не важными, но ресурсов оценить это под нагрузкой просто нет, поэтому все не срочное остается в беклоге, а срочное уходит в "что буду делать". А то что уже в работе этот принцип подвинуть уже не дает: свободных слотов в "что делаю" нет, пока что-то оттуда не уйдет в "что сделано".
Между беклогом и "что буду делать" перемещения карточек свободные - это нормально, обстоятельства меняются, задачи меняют порядок очередности или отменяются.
Внутри доски "что делаю" перемещения карточек также свободные: это твой островок свободы - можешь переключаться между слотами как угодно, по настроению, но выбор у тебя ограничен только теми 3 задачами что есть в этих слотах, будь добр выбери что-то одно и займись этим.
Доска "что буду делать" нужна для сортировки задач по приоритету. Особых ограничений нет, но если там накапливается слишком много карточек, лишние лучше скинуть обратно в беклог, чтобы разгрузить мозг: поддерживать порядок больше десятка карточек сложно. По мере опустошения доски, накидываешь на неё карточек из беклога в любом порядке. Срочные задачи также попадают на неё, вытесняя остальные задачи в беклог.
Ну а доска "что сделал" служит для мотивации и отчетов: наглядно видно сколько много работы ты сделал, и всегда можешь четко сказать что именно было сделано, да и вообще что и в каком статусе. Сами движения карточек между досками также мотивируют: позволяют увидеть, что работа работается, все хорошо, ничего не простаивает, а значит ты крут.
Получается что-то вроде процессора в миниатюре: ты в роли исполнительного блока, работаешь только с небольшим объемом задач в виде слотов на доске "что делаю", задачи получаешь из кеша в виде доски "что буду делать" с сортировкой по приоритету, и занимаешься тем, что перекидываешь карточки из "что буду делать" в "что сделано" через "что делаю", попутно выполняя необходимую работу. Выстраивается некий конвеер, монотонно перемалывающий задачи. Правила и ограничения на нем защищают исполнителя от перегрузки.
По задержкам ситуация хорошо разобрана тут https://habr.com/ru/company/vk/blog/594633/
На самом деле, из-за особенностей протоколов, проблема серьезнее, чем принято считать. К сожалению решения как правило принимает менеджмент, а он смотрит только на доступность в Москве, остальной мир не интересен. В итоге получается полный бред.
Я думаю не все так плохо. Просто в международные проекты не нужно допускать политику, и всё. Политику стоит оставить политикам. Большинству людей она не интересна.
Эм, это же классическая задача вывода листинга. Решается через отдельный интерфейс с пагинацией. Обычно он же поддерживает сортировку, в том числе по нескольким произвольным полям. Работает быстро как раз за счёт того, что лишние данные реально не запрашиваются, даже на уровне БД. Зачем тут велосипед - решительно непонятно.
Если судить по человеку, то всё намного проще: большая часть организма интеллектом вообще никак не контролируется. Те же автоматические реакции и рефлексы - сигналы замыкаются по короткому пути через отдельную простейшую нейронную сеть. Сам мозг по большей части гибридная машина, состоящая из множества отдельных специализированных нейронных сетей, решающих свои конкретные задачи. А интеллект в этой структуре занимает относительно небольшие мощности, сидит где-то глубоко, снимает высокоуровневые сигналы, работает с памятью, и вырабатывает высокоуровневые решения. Т.е. по большей части наш организм работает автоматически, гоняя по сетям огромные потоки данных, из которых до сознания доходит лишь капля информации.
Так что думаю для ИИ требуются не такие большие ресурсы, как для всего мозга. Основная задача: работа с памятью и обработка простейших высокоуровневых сигналов, заранее расжеванных и распознанных толстыми низкоуровневыми слоями (конкретно наш мозг ещё заранее из памяти вытаскивает нужные образы, предоставляя сознанию уже одни абстракции). На программном уровне все низкоуровневые слои можно даже не проектировать, заменив их заглушками. Остаётся только спроектировать ядро и интерфейсы к памяти, сигнальным и управляющим контурам.
Задача ещё сильнее упрощается, если не ориентироваться на человека, а просто пытаться создать специализированный ИИ, решающий узкий круг задач. В таком случае ядро схлопывается в чуть более сложный аналог правил из цепочек условий, но сдобренный нейросетями и работающий с памятью.
Но сам по себе ИИ без контроля малоэффективен, поэтому сверху нужен какой-нибудь ещё более простой контрольный контур, задача которого сводится к выработке обратной связи на решения основного ИИ, чтобы ИИ развивался в требуемую сторону. Традиционные нейросетки принято обучать заранее, с ИИ так не получится, он должен быть гибким, и уметь подстраиваться под ситуацию, меняться.
И в конце концов мы приходим к тому, что основные компоненты ИИ - это выработанные на основе опыта правила и состояние памяти. Эти абстракции работают даже на нашем уровне: вся личность человека определяется его опытом и памятью, лиши человека памяти - лишишь его личности, внуши ложную память - получишь ложную личность, опыт отнять нельзя, а память можно. Думаю в случае развития программного ИИ или появления каких-либо ИИ-компаньонов, дампы памяти будут массово тиражироваться, и скорее всего появится возможность их сколь-либо осмысленно препарировать и изменять, обеспечивая обмен тематическими пакетами знаний.
Просто оставлю это здесь https://www.youtube.com/watch?v=cLJCUqINdoI&t=870s