Прости, но я не нанимался для этого. Если интересна именно тема патопрома, то как вариант могу посоветовать это видео - https://youtu.be/7CIueLcE1xM?si=sKBICzkatuZw5ono.
Господи, ну какие оправдания? Есть история. У нас, у других, вообще у всех. Смотришь историю и понимаешь, почему у нас так, а у них - может быть не так. Почему Китай сейчас производит чипы, а мы - нет. Почему у Швеции нет ядерного оружия, а у нас - есть. Почему у США нет атомных ледоколов, а у нас - есть. Почему Тайвань производит чипы в промышленных масштабах, а мы - нет. Смысл, думаю, понятен. Всё это объяснимо историческим путём, который прошла та или иная страна. Оправдания - это уровень отдельно взятого человека, а люди везде одинаковые, Россия ничем в этом плане не отличается от остальных стран. Все везде одинаково ищут оправдания своим неудачам, но тем, кто живёт в России кажется, что это только тут так. Однако это им лишь так кажется, потому что они находятся именно здесь и именно сейчас.
Я не берусь утверждать, что всё то, что изготовлено в России - это стыд и позор. Вполне имееют место такие явления, как ёмобиль, нескучные обои, российская электроника, которая на деле китайская, сыплющийся автопром и другое. Я лишь утверждаю, что причина этих явлений - не то, что они родом из России, а гораздо комплекснее и не всегда лежит на поверхности. Взять, например, тот же автопром. Для того чтобы хаять его, много ума не нужно. Но для того чтобы в полной мере понять и осознать причины сложившейся ситуации с личным автотранспортом, придётся копнуть чуть ли не на 150 лет назад и проследить историю развития автостроения с царских времён. Но это придётся продумать.
А если действительно хочется посмотреть на импортозамещение, то, думаю, можно поскроллить этот сайт: https://sdelanounas.ru/.
так же как создали АтсраЛинукс, электронный планшет и ёмобиль!
Чувствую я, здесь сарказмом отдаёт. Ты считаешь, что ничего из этого не стоило создавать? Я в курсе, что планшет и ёмобиль это какой-то скам, но, как мне кажется, ты не только их имел ввиду?
Та же фигня была только что. Изменял конфиг что руками, что через GUI - всё равно не пуллил образы. Решил кардинально - переустановил DockerDesktop, добавил строку в daemon.json - и образы начали подсасываться.
Ну про закрыть канал писателем - это очевидно же.... но только если пишет один....
В случае многих писателей можно смело утверждать, что эти писатели тоже где-то создаются и кем-то ожидаются. Соответственно, этот кто-то ждёт пока отработают все писатели и закрывает канал, в который отправлялись данные.
Не знаю зачем я тут вклиниваюсь, но всё же вклинюсь. Таки согласен. Не понимаю, почему людей так интересуют именно декораторы в питоне, ведь этот паттерн реализуем везде, где можно объявлять функции высшего порядка. Всё то же самое можно делать и в каком-нибудь условном JS, только без синтаксического сахара.
Когда думаешьо декораторе просто как о функции, принимающей в качестве аргумента другую функцию, вся магия куда-то улетучивается.
Что не так? Автор этого кода явно прописал, что происходит только обработка значений true и false. Если там, например, null или, не дай бог, пустой массив (мне доводилось видеть всякое), ничего не произойдёт.
совсем не понимаю, что в этих запросах может быть сложного
Вот эта ремарка вызывает ощущение, будто автор очень мало и очень поверхностно поработал как с ORM, так и с SQL. Хотя сама статья, если честно, вызвала прямо противоположные чувства.
Можно сколько угодно спорить о том, какой подход более "трушный" - замаппить данные самостоятельно или использовать ORM. Но вот сомневаться в сложности как одного, так и второго метода - как минимум подозрительно.
Самое первое, что приходит мне на ум, когда я слышу о том, что писать запросы (на чистом SQL или через ORM - не важно) это просто - это попросить автора этих слов разобрать порядок выполнение какого-нибудь более-менее сложного запроса. Хотя бы в пределах одной СУБД. В каком порядке будет выполняться запрос? Какие индексы будут задействоваться? А будут ли они задействоваться? А как сделать так, чтобы они задействовались? А что произойдёт, если данных будет очень много? А можно ли переписать запрос более эффективно?
Сложно ли это для опытного инженера, съевшего собаку на проектировании баз данных? Вряд ли. Сложно ли это рядовому разработчику, от которого бизнес требует что-то там оптимизировать? Определённо сложно. Настолько сложно, что в некоторых случаях даже и не знаешь, что тебе загуглить чтобы решить вот эту конкретную проблему.
Да, знаю про такой, спасибо за дополнение. Именно реализация аннотаций от EmmyLua была взята за основу в языковом сервере для VSCode. Кстати, вы можете сделать доброе дело и поделиться вашими наработками, опубликовав плагин с типами Тарантула, подробности в этой доке ;)
Второй монитор с документацией на удивление творит чудеса, очень советую : )
Подозреваю, что этот пункт просто ради рофла, иначе мне придётся выяснять, как монитор переносить в рюкзаке :)
Динамические системы автодополнения.
Да, VSCode умеет запоминать введённые слова и в дальнейшем предлагать их для автодополнения. Но всё же это не то же самое, что ввести имя переменной, точку и в выпавшем списке просматривать доступные методы и свойства. А хотелось именно этого.
{fromJust: "WTF? String is not a number!"} расширяет {} - любой объект, поэтому компилятор считает, что это Nothing , а не Just<Number> . По сути, тип Maybe<A> определён как какой угодно объект или {fromJust: A} . Потому эта запись валидна.
Прости, но я не нанимался для этого. Если интересна именно тема патопрома, то как вариант могу посоветовать это видео - https://youtu.be/7CIueLcE1xM?si=sKBICzkatuZw5ono.
На основании одной новости был сделан вывод обо всех остальных новостях на сайте? Что ж, это очень по-взрослому.
По существу, я так понимаю, ответить нечего.
Так как я не ною по каждому поводу - мне не надоело, да.
Господи, ну какие оправдания? Есть история. У нас, у других, вообще у всех. Смотришь историю и понимаешь, почему у нас так, а у них - может быть не так. Почему Китай сейчас производит чипы, а мы - нет. Почему у Швеции нет ядерного оружия, а у нас - есть. Почему у США нет атомных ледоколов, а у нас - есть. Почему Тайвань производит чипы в промышленных масштабах, а мы - нет. Смысл, думаю, понятен. Всё это объяснимо историческим путём, который прошла та или иная страна. Оправдания - это уровень отдельно взятого человека, а люди везде одинаковые, Россия ничем в этом плане не отличается от остальных стран. Все везде одинаково ищут оправдания своим неудачам, но тем, кто живёт в России кажется, что это только тут так. Однако это им лишь так кажется, потому что они находятся именно здесь и именно сейчас.
Для чего ты подменяешь понятия?
Я не берусь утверждать, что всё то, что изготовлено в России - это стыд и позор. Вполне имееют место такие явления, как ёмобиль, нескучные обои, российская электроника, которая на деле китайская, сыплющийся автопром и другое. Я лишь утверждаю, что причина этих явлений - не то, что они родом из России, а гораздо комплекснее и не всегда лежит на поверхности. Взять, например, тот же автопром. Для того чтобы хаять его, много ума не нужно. Но для того чтобы в полной мере понять и осознать причины сложившейся ситуации с личным автотранспортом, придётся копнуть чуть ли не на 150 лет назад и проследить историю развития автостроения с царских времён. Но это придётся продумать.
А если действительно хочется посмотреть на импортозамещение, то, думаю, можно поскроллить этот сайт: https://sdelanounas.ru/.
Странная логика - вспоминать только о плохом, но (намеренно?) забывать упомянуть что-то хорошее.
Чувствую я, здесь сарказмом отдаёт. Ты считаешь, что ничего из этого не стоило создавать? Я в курсе, что планшет и ёмобиль это какой-то скам, но, как мне кажется, ты не только их имел ввиду?
Та же фигня была только что. Изменял конфиг что руками, что через GUI - всё равно не пуллил образы. Решил кардинально - переустановил DockerDesktop, добавил строку в daemon.json - и образы начали подсасываться.
Да, первого апреля.
В случае многих писателей можно смело утверждать, что эти писатели тоже где-то создаются и кем-то ожидаются. Соответственно, этот кто-то ждёт пока отработают все писатели и закрывает канал, в который отправлялись данные.
Не знаю зачем я тут вклиниваюсь, но всё же вклинюсь. Таки согласен. Не понимаю, почему людей так интересуют именно декораторы в питоне, ведь этот паттерн реализуем везде, где можно объявлять функции высшего порядка. Всё то же самое можно делать и в каком-нибудь условном JS, только без синтаксического сахара.
Когда думаешьо декораторе просто как о функции, принимающей в качестве аргумента другую функцию, вся магия куда-то улетучивается.
Очевидно кому?
Использование апелляции к очевидности говорит мне о том, что по существу вам всё же нечего написать.
А я совета не просил) Я попросил объяснить, что не так в коде автора?
Смешно. Нет.
Что не так? Автор этого кода явно прописал, что происходит только обработка значений true и false. Если там, например, null или, не дай бог, пустой массив (мне доводилось видеть всякое), ничего не произойдёт.
Вот эта ремарка вызывает ощущение, будто автор очень мало и очень поверхностно поработал как с ORM, так и с SQL. Хотя сама статья, если честно, вызвала прямо противоположные чувства.
Можно сколько угодно спорить о том, какой подход более "трушный" - замаппить данные самостоятельно или использовать ORM. Но вот сомневаться в сложности как одного, так и второго метода - как минимум подозрительно.
Самое первое, что приходит мне на ум, когда я слышу о том, что писать запросы (на чистом SQL или через ORM - не важно) это просто - это попросить автора этих слов разобрать порядок выполнение какого-нибудь более-менее сложного запроса. Хотя бы в пределах одной СУБД. В каком порядке будет выполняться запрос? Какие индексы будут задействоваться? А будут ли они задействоваться? А как сделать так, чтобы они задействовались? А что произойдёт, если данных будет очень много? А можно ли переписать запрос более эффективно?
Сложно ли это для опытного инженера, съевшего собаку на проектировании баз данных? Вряд ли. Сложно ли это рядовому разработчику, от которого бизнес требует что-то там оптимизировать? Определённо сложно. Настолько сложно, что в некоторых случаях даже и не знаешь, что тебе загуглить чтобы решить вот эту конкретную проблему.
Да, знаю про такой, спасибо за дополнение. Именно реализация аннотаций от EmmyLua была взята за основу в языковом сервере для VSCode. Кстати, вы можете сделать доброе дело и поделиться вашими наработками, опубликовав плагин с типами Тарантула, подробности в этой доке ;)
Подозреваю, что этот пункт просто ради рофла, иначе мне придётся выяснять, как монитор переносить в рюкзаке :)
Да, VSCode умеет запоминать введённые слова и в дальнейшем предлагать их для автодополнения. Но всё же это не то же самое, что ввести имя переменной, точку и в выпавшем списке просматривать доступные методы и свойства. А хотелось именно этого.
{fromJust: "WTF? String is not a number!"}расширяет{}- любой объект, поэтому компилятор считает, что этоNothing, а неJust<Number>. По сути, типMaybe<A>определён как какой угодно объект или{fromJust: A}. Потому эта запись валидна.