Условный yield, который делает ожидание семафора, переводит статус текущего процесса в "спящий", что означает что планировщик задач не будет его рассматривать в качестве кандидата на запуск. И далее вызывается планировщик процессов, который выбирает следующий процесс из числа готовых к выполнению. А операция разблокирования семафора обратно переключает статус процесс на "готов к выполению". То есть в какой-то момент планировщик выберет наш первый процесс и он продолжит выполнение с той же точки.
Так вот, обработчик прерывания - это совершенно другой случай, планировщик задач их не контролирует. Нет механизма запомнить точку в обработчике прерывания, поделать что-то еще и вернуться туда же (кроме явного вызова какой-то функции :)).
Ну и ко всему внутри обработчика прерывания прерывания на этом процессоре выключены. То есть при попытке поспать этот процессор просто зависнет навсегда.
Вместо каждого видео можно было просто вставить скриншот и написать абзац текста, вы один раз пишете а статью читает множество людей. Вы лишние пять минут сэкономили себе а тысяча людей потратит на 5 минут больше на прочтение-осознание статьи.
Query сильно ухудшает читаемость кода, лучше по-максимуму использовать Select, в котором и ошибиться нереально и занимает он всего 3-4 строчки. Писать-читать такой код очень легко и понятно.
Я же наоборот сказал, что не бывает задач переписать все функции для работы с БД, поэтому и объединять их (в один слой) не нужно.
Объединять нужно то, что используется вместе а разделять - то что вместе не используется и не связано. хендлер1-бизнес логика1-запрос в базу1 для одной конкретной апишки всегда используется вместе, поэтому их надо объединить. А хендлер2-бизнес логика2-запрос в базу2 другой апишки не связан с хендлер1-бизнес логика1-запрос в базу1 поэтому их надо отделить на самом верхнем уровне.
Я считаю вообще деление на слои выглядит логичным но крайне неудобно в написании и поддержке. Вместо деления на слои надо максимально делить на операции а внутри каждой операции можно делать столько слоев-функций, сколько необходимо.
Потому что не бывает задач "переписать все функции для работы с БД" или "доработать все обработчики HTTP" зачем их тогда группировать?
Напротив, 95% всех задач - это либо сделать/доработать новую операцию (добавить операцию по смене статуса заказа, добавить новый фильтр в список заказов). Либо найти баг/оптимизировать (тормозит выдача списка заказов, 404 при попытке смене заказа). И вот для решения таких задач хочется чтобы ВЕСЬ код, который реализует эту операцию находился в одной папке и кроме кода, относящегося к этой операции в этой папке больше ничего не было.
Да, если такой подход реализовать в лоб, будет куча копипасты, но как всегда, можно чуть подумать и сделать общие функции, например.
Такая аналогия: вы увлекаетесь разными видами спорта и есть 2 подхода к хранению снаряжения:
Шкаф для шлемов, шкаф для курток, шкаф для обуви, комната/гараж для основных снарядов
Делить по видам спорта: чулан для велосипеда а рядом сумка с велотуфлями, велошлемом и велоформой. Гараж для мотоцикла + ящик для мотоформы. Шкаф для коньков и хоккейной формы.
Несмотря на то, что при первом подходе на вид будет порядок второй подход будет требовать гораздо меньших затрат времени - открываешь шкаф для хоккея и надеваешь все что там есть. Не надо открывать 5 разных шкафов в двух комнатах.
Если опять пример с домом рассмотреть, сделать колодец диаметром 1 метр, в качестве груза взять чугунные цилиндры (чугун 25000 за тонну стоит) и забивать ими весь колодец - то колодец нужен будет глубиной всего 25 метров. Но стоимость чугуна получается 6млн рублей )
Я проголосовал за то, что не получится. Просто в статье чисел нет, а интересно как раз оценить :)
Если мы возьмем свинцовый груз 10x10x10 метров и опустим его на километр, то это запасет энергию 10 * 10 * 10 * 11.35 * 1000 * 1000 * 9.8 = 111230000000 Джоулей, это 30897 киловатт-часов. То есть хватит чтобы 50 квартир обеспечить энергией на месяц. И особых потерь энергии не будет разве что если всю эту махину весом 11 тысяч тонн просто на тросе подвесить. Если как на картинке что-то разгружать и на роботизированых тачках отвозить в сторонку, потери будут гораздо больше а цена такой системы гиганская.
Ну и другой пример - допустим у нас дом (частный) с солнечными батареями, которые весь день генерят энергию и запасают в гравитационном аккумуляторе, а ночью мы пользуемся этим аккумулятором и допустим у нас груз - кубометр свинца. За вечер-ночь дом расходует 600/30/2 = 10 квт*ч : 3.6e+7 / (11.35 * 1000 * 9.8) = 323 метра.
Выкопать колодец на 300 метров рядом с домом - ну, реально конечно, но я думаю это очень дорого.
Девушка явно не на соревновании бежит, скорее всего у нее нет цели пробежать много километров за минимальное время, поэтому в целом как угодно может бежать. А мужики из моих видео бегут 42км на время.
Противоречия в тексте от гармина нет. Там же написано, что типа в целом лучше прыгать пониже, но стремиться уменьшать именно этот показатель не надо, лучше смотреть на вертикальное соотношение: типа лучше делать шаг 2 метра и прыгать на 10см вверх, чем шаг 1м и прыгать на 8см. У пузатых будет очень короткий шаг, поэтому ничего хорошего они не смогут выдать.
Спортивные часы гармин народ покупает более-менее подготовленный. Те кто "решили начать бегать в 2023" скорее всего купят какой-то фитнесс-браслет за 3000 или будут с эпл вотч бегать. Не самые красивые и функциональные часы за 30 тысяч они точно не будут брать.
Амортизаторы на сжатие пружины тратят только часть энергии, другая часть тратится на нагрев масла. Это вам любой велосипедист скажет, иначе бы никто не делал вилки с блокировкой. Ноги вообще от идеальной пружины очень далеки. Я думаю они вообще никакой энергии не запасают при сжатии.
Изменяется это нагрудным ремнем с акселерометром типа такого https://www.garmin.ru/remeshki/catalog/pulsometry/run/ Гарминовские спортивные часы, наверное, большинство бегунов используют, и эти часы по умолчанию все тренировки в облако загружают. Так что статистика у гармина гигантская и очень точная.
Девушка коленям не навредит, но с такой техникой хороший результат не сможет показать. По фото мужика ничего не видно :(
https://www.youtube.com/watch?v=Fw2ShMUzY-o - вот тут хорошо видно. Оба практически не подпрыгивают и ноги на землю ставят очень плавно. В целом необходимости явно на носок ставить наверное нет с такой техникой, но все-равно видно что человек сзади приземляется на носок и потом уже касается пяткой.
Короче надо чтоб не было ударных нагрузок ни на какую часть тела. Если на крутых бегунов на длинные дистанции посмотреть - они очень плавно бегут, как будто парят над землей.
Надо просто во-первых, приземляться не на пятку, а на носок, как животные. А во-вторых, когда уже научились на носок приземляться - не "втыкать" носок в землю. Если есть сомнения - наверное надо с тренером позаниматься.
Я особо часто не тренировался никогда, больше двух раз в неделю не бегал, всегда бегал больше 8км за тренировку (по моему состоянию нет смысла меньше часа бегать). Пробежал 3 раза марафон с довольно скромным временем, лучшее 4:14 вроде было, причем готовиться-бегать начинал месяца за 4 до него (к сожалению :(, мог бы получше результат показать). Пока всё нормально с коленями.
Да, очень странно отбирать у человека деятельность, которая очень приятная, интересная и приносит огромное удовольствие. По-моему еще много всего можно автоматизировать, чем человек не особо любит заниматься.
Как минимум у книги должен быть автор, который является реальным человеком, потом книга тоже не из воздуха берется, этот человек-автор должен как-то объяснить первым читателям, кто он такой и для чего написал эту книгу.
Можно конечно придумать подставного писателя, который будет под своим именем выпускать книги, которые написал ИИ, но, боюсь, быстро его раскусят.
Условный yield, который делает ожидание семафора, переводит статус текущего процесса в "спящий", что означает что планировщик задач не будет его рассматривать в качестве кандидата на запуск. И далее вызывается планировщик процессов, который выбирает следующий процесс из числа готовых к выполнению. А операция разблокирования семафора обратно переключает статус процесс на "готов к выполению". То есть в какой-то момент планировщик выберет наш первый процесс и он продолжит выполнение с той же точки.
Так вот, обработчик прерывания - это совершенно другой случай, планировщик задач их не контролирует. Нет механизма запомнить точку в обработчике прерывания, поделать что-то еще и вернуться туда же (кроме явного вызова какой-то функции :)).
Ну и ко всему внутри обработчика прерывания прерывания на этом процессоре выключены. То есть при попытке поспать этот процессор просто зависнет навсегда.
Вместо каждого видео можно было просто вставить скриншот и написать абзац текста, вы один раз пишете а статью читает множество людей. Вы лишние пять минут сэкономили себе а тысяча людей потратит на 5 минут больше на прочтение-осознание статьи.
Лучше бы сделали возможность наоборот, запретить себе брать любые кредиты без физического посещения офиса с паспортом и face id.
Там там же всё действие в закрытой зоне происходит, это просто забор как бы. И через него хорошо видно окружающий пейзаж.
Query сильно ухудшает читаемость кода, лучше по-максимуму использовать Select, в котором и ошибиться нереально и занимает он всего 3-4 строчки. Писать-читать такой код очень легко и понятно.
Я же наоборот сказал, что не бывает задач переписать все функции для работы с БД, поэтому и объединять их (в один слой) не нужно.
Объединять нужно то, что используется вместе а разделять - то что вместе не используется и не связано. хендлер1-бизнес логика1-запрос в базу1 для одной конкретной апишки всегда используется вместе, поэтому их надо объединить. А хендлер2-бизнес логика2-запрос в базу2 другой апишки не связан с хендлер1-бизнес логика1-запрос в базу1 поэтому их надо отделить на самом верхнем уровне.
В последнем абзаце согласен с автором.
Я считаю вообще деление на слои выглядит логичным но крайне неудобно в написании и поддержке. Вместо деления на слои надо максимально делить на операции а внутри каждой операции можно делать столько слоев-функций, сколько необходимо.
Потому что не бывает задач "переписать все функции для работы с БД" или "доработать все обработчики HTTP" зачем их тогда группировать?
Напротив, 95% всех задач - это либо сделать/доработать новую операцию (добавить операцию по смене статуса заказа, добавить новый фильтр в список заказов). Либо найти баг/оптимизировать (тормозит выдача списка заказов, 404 при попытке смене заказа). И вот для решения таких задач хочется чтобы ВЕСЬ код, который реализует эту операцию находился в одной папке и кроме кода, относящегося к этой операции в этой папке больше ничего не было.
Да, если такой подход реализовать в лоб, будет куча копипасты, но как всегда, можно чуть подумать и сделать общие функции, например.
Такая аналогия: вы увлекаетесь разными видами спорта и есть 2 подхода к хранению снаряжения:
Шкаф для шлемов, шкаф для курток, шкаф для обуви, комната/гараж для основных снарядов
Делить по видам спорта: чулан для велосипеда а рядом сумка с велотуфлями, велошлемом и велоформой. Гараж для мотоцикла + ящик для мотоформы. Шкаф для коньков и хоккейной формы.
Несмотря на то, что при первом подходе на вид будет порядок второй подход будет требовать гораздо меньших затрат времени - открываешь шкаф для хоккея и надеваешь все что там есть. Не надо открывать 5 разных шкафов в двух комнатах.
Если опять пример с домом рассмотреть, сделать колодец диаметром 1 метр, в качестве груза взять чугунные цилиндры (чугун 25000 за тонну стоит) и забивать ими весь колодец - то колодец нужен будет глубиной всего 25 метров. Но стоимость чугуна получается 6млн рублей )
Я проголосовал за то, что не получится. Просто в статье чисел нет, а интересно как раз оценить :)
Если второй пример пересчитать на вот такие аккумуляторы - https://market.yandex.ru/product--akkumuliatornaia-batareia-akb-dlia-elektrosamokata-xiaomi-mijia-m365-pro-36v-12800-mach/1761629471
То это всего 20 акккумуляторов, 320 т.р.
Если мы возьмем свинцовый груз 10x10x10 метров и опустим его на километр, то это запасет энергию 10 * 10 * 10 * 11.35 * 1000 * 1000 * 9.8 = 111230000000 Джоулей, это 30897 киловатт-часов. То есть хватит чтобы 50 квартир обеспечить энергией на месяц. И особых потерь энергии не будет разве что если всю эту махину весом 11 тысяч тонн просто на тросе подвесить. Если как на картинке что-то разгружать и на роботизированых тачках отвозить в сторонку, потери будут гораздо больше а цена такой системы гиганская.
Ну и другой пример - допустим у нас дом (частный) с солнечными батареями, которые весь день генерят энергию и запасают в гравитационном аккумуляторе, а ночью мы пользуемся этим аккумулятором и допустим у нас груз - кубометр свинца. За вечер-ночь дом расходует 600/30/2 = 10 квт*ч : 3.6e+7 / (11.35 * 1000 * 9.8) = 323 метра.
Выкопать колодец на 300 метров рядом с домом - ну, реально конечно, но я думаю это очень дорого.
Девушка явно не на соревновании бежит, скорее всего у нее нет цели пробежать много километров за минимальное время, поэтому в целом как угодно может бежать. А мужики из моих видео бегут 42км на время.
Противоречия в тексте от гармина нет. Там же написано, что типа в целом лучше прыгать пониже, но стремиться уменьшать именно этот показатель не надо, лучше смотреть на вертикальное соотношение: типа лучше делать шаг 2 метра и прыгать на 10см вверх, чем шаг 1м и прыгать на 8см. У пузатых будет очень короткий шаг, поэтому ничего хорошего они не смогут выдать.
Спортивные часы гармин народ покупает более-менее подготовленный. Те кто "решили начать бегать в 2023" скорее всего купят какой-то фитнесс-браслет за 3000 или будут с эпл вотч бегать. Не самые красивые и функциональные часы за 30 тысяч они точно не будут брать.
Амортизаторы на сжатие пружины тратят только часть энергии, другая часть тратится на нагрев масла. Это вам любой велосипедист скажет, иначе бы никто не делал вилки с блокировкой. Ноги вообще от идеальной пружины очень далеки. Я думаю они вообще никакой энергии не запасают при сжатии.
Изменяется это нагрудным ремнем с акселерометром типа такого https://www.garmin.ru/remeshki/catalog/pulsometry/run/ Гарминовские спортивные часы, наверное, большинство бегунов используют, и эти часы по умолчанию все тренировки в облако загружают. Так что статистика у гармина гигантская и очень точная.
А вот как ваша девушка подпрыгивает, явно побольше тут. Про то что она на носки хорошо приземляется я же написал, к этому то нет претензий.
Вот справка из garmin online
Девушка коленям не навредит, но с такой техникой хороший результат не сможет показать. По фото мужика ничего не видно :(
https://www.youtube.com/watch?v=Fw2ShMUzY-o - вот тут хорошо видно. Оба практически не подпрыгивают и ноги на землю ставят очень плавно. В целом необходимости явно на носок ставить наверное нет с такой техникой, но все-равно видно что человек сзади приземляется на носок и потом уже касается пяткой.
Короче надо чтоб не было ударных нагрузок ни на какую часть тела. Если на крутых бегунов на длинные дистанции посмотреть - они очень плавно бегут, как будто парят над землей.
Надо просто во-первых, приземляться не на пятку, а на носок, как животные. А во-вторых, когда уже научились на носок приземляться - не "втыкать" носок в землю. Если есть сомнения - наверное надо с тренером позаниматься.
Я особо часто не тренировался никогда, больше двух раз в неделю не бегал, всегда бегал больше 8км за тренировку (по моему состоянию нет смысла меньше часа бегать). Пробежал 3 раза марафон с довольно скромным временем, лучшее 4:14 вроде было, причем готовиться-бегать начинал месяца за 4 до него (к сожалению :(, мог бы получше результат показать). Пока всё нормально с коленями.
Где же тут качество зеркалки интересно? Качество съемки видео зеркалкой 2008 года выпуска что-ли?
А где их можно найти? В Google Play ни первого ни второго не могу найти
Да, очень странно отбирать у человека деятельность, которая очень приятная, интересная и приносит огромное удовольствие. По-моему еще много всего можно автоматизировать, чем человек не особо любит заниматься.
Как минимум у книги должен быть автор, который является реальным человеком, потом книга тоже не из воздуха берется, этот человек-автор должен как-то объяснить первым читателям, кто он такой и для чего написал эту книгу.
Можно конечно придумать подставного писателя, который будет под своим именем выпускать книги, которые написал ИИ, но, боюсь, быстро его раскусят.