Ровно по тем же причинам, почему коробка-автомат плохо подходит для обучения вождению. Почему детей сначала учат таблице умножения, а уже потом дают калькулятор. Да потому что процесс обучения начинается с элементарных основ - математика с арифметики, музыка с нот, а электротехника с лампочки и батарейки. Если вам с вашим первым языком дали из коробки ООП, встроенные структуры, сборщик мусора и пр. то каким образом у вас сформируется понимание, а зачем собственно все это нужно и какие проблемы решает? А главное, как это все дефолтное разумно применять?
А что делать, если двум приложениям требуются разные, несовместимые версии пакетов?
Объясните, пожалуйста, тупому, а почему зависимости нельзя просто версионировать? Допустим, приложению Калькулятор нужна библиотека libabc версии 0.25, а для приложения Календарь libabc версии 0.31. Ну и бога ради, пусть они обе одновременно присутствуют в соответствующих подкаталогах. Пакетный менеджер при установке пакета пишет в какой-нибудь реестр, какая приложенька зависит от какой версии, а ядро при линковке обращается к этому реестру и выбирает нужную версию. При удалении пакета можно пройтись по реестру и вычислить, нужна ли зависимость какому-то другому пакету, и если не нужна, то она удаляется. То же самое при обновлении - в реестр записали новые зависимости и удалили старые, если они больше никому не нужны. Для замособранных программ, которых нет в реестре, по дефолту вибирается самая свежая версия библиотеки.
Вот у нас есть какой-то код, допустим, он получает некие данные и сериализует их в JSON. И у нас есть две имплементации - на Си и на чистом питоне. И, скажем, код на Си работает в 100 раз быстрее. Очевидно преимущество Си. Но это пока мы не начнем применять этот код на практике. Когда приложение 50 миллисекунд ковыряется в БД, потом сериализует ответ в JSON и отправляет на клиент, то вообще не важно займет сериализация 0.1 миллисекунду или целую миллисекунду, потому что узкое место - СУБД, и заменив питон на Си вы не получите 100-кратное увеличение производительности, вы получите только около 1,5%
складывается мировоззрение о том, что всё должно быть объектами
Ну то есть уважаемый преподаватель вот так вот просто взял и огульно обозвал всю Java антипаттерном. Бедному студенту только что на другой паре активно объясняли преимущества подхода "все есть объект", и вот нате вам, оказывается это антипаттерн. А потом он встретит препода влюбленного в лисп и ему будут продувать мозги иммутабельностью и что все это ваше ООП гавно, а потом апологет чистого кода обзовет говнокодом решение уважаемого автора, потому что у него функция четырех аргументов. А потом человек попадет в команду и там будет своя атмосфера и свои гайдлайны исторически сложившиеся. А по факту все это вообще вкусовщина, и препод занимается вообще не тем, и вместо гибкого мышления насаждает студентам свои привычки.
При этом статья очень слабая и даже местами вредная.
Декоратор – не что иное, как функция
это неверное утверждение
т.е. декоратор будет вызван только тогда, когда вы «вызовете» класс.
и это тоже не правда
Декорирование класса в Python работает как изменение класса извне (т.е. из декоратора).
что прямо противоположно утверждению "декоратор будет вызван только тогда, когда вы «вызовете» класс. Вызов класса означает создание его экземпляра" и является в общем-то чушью
только его конструктор (метод init)
инит это не конструктор
ну и так далее. Зачем это было написано? Это даже не плохо процитированный учебник, это записки студента на полях. При желании можно было бы написать полезную статью про декораторы. Как сделать универсальный декоратор для которого не обязательны скобки при отсутствии параметров, как сделать декоратор с состоянием, как совместно использовать мощь декораторов и дескрипторов, например.
Когда на безсерверную службу придет запрос на выполнение кода, облачный провайдер просто выделит специально под его обработку виртуальную машину или модуль (набор контейнеров, обычно управляемых Kubernetes).
Как это работает, более-менее понятно, а как это программировать то? Допустим, у меня есть веб-сервер на python + Django. Он состоит из набора view, каждая вьюшка - функция, казалось бы - вот оно. Но есть же еще, скажем, ОРМ. Для инициализации моделей, построения дерева отношений и пр. требуется время. В обычном "серверном" сценарии мы жертвуем несколькими секундами "на разогрев" на этапе импорта, один раз для процесса. Далее обработка каждого входящего запроса - ну то есть каждого вызова функции - эта работа не нужна, все уже в памяти процесса. Правильно ли я понимаю, что с модными молодежными безсерверными технологиями мне прийдется вручную строить SQL запросы в стиле PHP пятнадцатилетней давности?
Периодически то в одном, то в другом фильме мелькает интересный девайс, который позволяет за доли секунд выключить: всю электронику в окрестностях, свет во всём городе, «победить всех роботов разом» и т.д. и т. п. Да, речь пойдёт о «мифическом» генераторе электромагнитного импульса. Но насколько он реален на самом деле?
Ответ на этот вопрос в статье, к сожалению, не прозвучал. Так как он, реален или нет?
Копирайтер написал статью, получил за это денежку, молодец. Редактор статью почитал, покритиковал, отредактировал - поработал одним словом, получил свою денежку - тоже молодец. Маркетолог, добавил какие-то одному ему ведомые цифры в квартальный отчет - его полезность и эффективность налицо. Фирма которая им всем платит напомнила читателям о своем существовании и, вероятно, увеличит свои доходы на какой-то процент, директор купит любовнице новый мерседес. Все счастливы! Вот я эту статью прочитал. И казалось бы - нечего возразить, не с чем спорить. Но дала ли мне эта статья какое-то новое знание, новую точку зрения или повод о чем-то задуматься? Да... нет. Так-то разобраться, здесь же капитаноочевидные вещи. Ну надо же идиотом быть, чтобы прийти на собеседование как разработчик и забыть спросить, какой же стек технологий твой потенциальный работодатель использует. Ну или на собеседовании просить показать задачи в бэклоге (вы в своем уме??). В общем, друзья, производите вы никому не нужную туфту в промышленных масштабах.
Десятки исследований на животных и людях показали, что обычное голодание улучшает метаболизм, снижает уровень сахара в крови, уменьшает воспаления от артритных болей до астмы, ускоряет вывод поврежденных клеток.
Я глубочайше уверен, что были десятки исследований (говоря о десятках, автор дает ссылку на единственную статью, из которой даже не вполне ясны условия эксперимента), которые показали противоположные результаты, или не показали никаких результатов. Или таких исследований не было? Или они не известны автору? Или они известны автору, но он сознательно о них не упоминает? Как-то это, коллеги, всё очень желтушно выглядит. Я ни коим образом не профессионал, но когда вижу что-то наподобие «ускоряет вывод поврежденных клеток», мне кажется вот ещё чуть-чуть и начнутся глупости про шлаки, очишения организма и уринотерапию. При чём, если поискать, то уверен, что есть десятки и сотни исследований, показывающих благотворное влияние упаренной урины на организм.
А что вы имеете в виду под ошибками? Погуглил — акции стабильно растут, капитализация увеливается, индексы там всякие — всё вроде в порядке, бизнес чувствует себя как никогда хорошо. Какие ошибки то?
Кто бы мне объяснил, ибо сам я не вполне понимаю, откуда у Мозилы вообще деньги на разработку браузера. У гугла понятно откуда, а у этих товарищей? Мне кажется, что весь этот бизнес строится на ожидании, кому бы из инвесторов продаться подороже. Вред ли стоит наивно полагать, что примерно тысяча разработчиков делают «лучший в мире браузер» сугубо из альтруизма и любви к СПО. Нужны бабки и немалые. Вот они и виляют жопой под повестку. То раст изобретут, то ОС пилить начнут, то в ЛГБТ ударятся — всё это брачные танцы перед действительно серьезным капиталом, который Мозилу кормит. Как кормить перестанут, тут ей и конец.
Сначала они уволили Брендана Айка, потому что пара геев на что-то там привычно обиделась. В след за ним ушел Хэмптон Кэтлин по той же причине. Потом Мозила заявила, что браузер они больше делать не хотят, а хотят делать Firefox OS. Потом они уволили часть сотрудников, потому что
Освободившиеся деньги хотят направить на приоритетные цели, в том числе защиту приватности и борьбу с трекингом пользователей.
потом они уволили еще 250 человек потому что
внимание компании будет сосредоточено на развитие других продуктов
Под увольнения попала вся команда реагирования на угрозы (Threat management team), занимавшаяся выявлением и разбором инцидентов, а также часть команды Security team. Увольнения затронули команду Mozilla Research, занимавшуюся разработкой движка Servo, написанного на языке Rust. Уволены все сотрудники из команды MDN (Mozilla Developer Network).
По-моему они сами себя активно топят и гугл здесь вовсе не при чём
Написано полностью в стиле современных тенденций — беззубо, размыто, не дай бог задеть чьи-то чувства. А если по-пролетарски откровенно, отбросив менеджерский новояз — «софт-скиллы» и тп., то можно сказать короче и по существу — чтобы работать в ИТ нужны мозги, которых у 95% населения нет, а желание заработать денюжек есть. Никуда нельзя деть тот факт, что люди бывают элементарно глупы.
Периодически в сети появляются наполненные внезапными открытиями статьи в стиле «Вы все неправильно понимаете ООП», где нам расскажут про Алана Кэя и его идеи 70-х годов, как будто эти идеи не имеют права на эволюцию, как будто это незыблемый закон природы, а современные программисты кощунственно извратив основы ввергают индустрию в пучину разврата, и просто необходимо канонизировать Кэя и отрубать руки за вольные трактровки его священных речей.
Это технология, она проходит проверку временем или не проходит. Полезные идеи приживаются, терминология меняется, подходы меняются. Да сам автор тогда в 90-х вряд-ли мог вообразить во что вревратится интернет в 2020-х.
Вот эта статья, мне кажется, в подобной же риторике написана. «Вы не правильно используете». Да идите вы к чёрту, господа, как надо, так и используем.
Должен заметить, что статья создает у читателя ложное ощущение, будто asyncio это безальтернативный способ построения асинхронных программ и добиться этого можно только с помощью async/await синтаксиса. Даже блок-схема однозначно сообщает, что если у вас питон версии ранее 3.5, то асинхронность не для вас. Что есть очевидная ложь.
Не согласен категорически.
Ровно по тем же причинам, почему коробка-автомат плохо подходит для обучения вождению. Почему детей сначала учат таблице умножения, а уже потом дают калькулятор. Да потому что процесс обучения начинается с элементарных основ - математика с арифметики, музыка с нот, а электротехника с лампочки и батарейки. Если вам с вашим первым языком дали из коробки ООП, встроенные структуры, сборщик мусора и пр. то каким образом у вас сформируется понимание, а зачем собственно все это нужно и какие проблемы решает? А главное, как это все дефолтное разумно применять?
Объясните, пожалуйста, тупому, а почему зависимости нельзя просто версионировать? Допустим, приложению Калькулятор нужна библиотека libabc версии 0.25, а для приложения Календарь libabc версии 0.31. Ну и бога ради, пусть они обе одновременно присутствуют в соответствующих подкаталогах. Пакетный менеджер при установке пакета пишет в какой-нибудь реестр, какая приложенька зависит от какой версии, а ядро при линковке обращается к этому реестру и выбирает нужную версию. При удалении пакета можно пройтись по реестру и вычислить, нужна ли зависимость какому-то другому пакету, и если не нужна, то она удаляется. То же самое при обновлении - в реестр записали новые зависимости и удалили старые, если они больше никому не нужны. Для замособранных программ, которых нет в реестре, по дефолту вибирается самая свежая версия библиотеки.
>Instagram? Disqus? Достаточно высоконагружены?
Ну, вероятно, не влияют
каким образом для NGINX узкое место - БД, потрудитесь объяснить, пожалуйста
Вот у нас есть какой-то код, допустим, он получает некие данные и сериализует их в JSON. И у нас есть две имплементации - на Си и на чистом питоне. И, скажем, код на Си работает в 100 раз быстрее. Очевидно преимущество Си. Но это пока мы не начнем применять этот код на практике. Когда приложение 50 миллисекунд ковыряется в БД, потом сериализует ответ в JSON и отправляет на клиент, то вообще не важно займет сериализация 0.1 миллисекунду или целую миллисекунду, потому что узкое место - СУБД, и заменив питон на Си вы не получите 100-кратное увеличение производительности, вы получите только около 1,5%
Да, но только профессор кажется этого сам не понял, раз пишет такие разоблачительные статьи, где как раз вкусовщиной и занимается.
Ну то есть уважаемый преподаватель вот так вот просто взял и огульно обозвал всю Java антипаттерном. Бедному студенту только что на другой паре активно объясняли преимущества подхода "все есть объект", и вот нате вам, оказывается это антипаттерн. А потом он встретит препода влюбленного в лисп и ему будут продувать мозги иммутабельностью и что все это ваше ООП гавно, а потом апологет чистого кода обзовет говнокодом решение уважаемого автора, потому что у него функция четырех аргументов. А потом человек попадет в команду и там будет своя атмосфера и свои гайдлайны исторически сложившиеся. А по факту все это вообще вкусовщина, и препод занимается вообще не тем, и вместо гибкого мышления насаждает студентам свои привычки.
При этом статья очень слабая и даже местами вредная.
это неверное утверждение
и это тоже не правда
что прямо противоположно утверждению "декоратор будет вызван только тогда, когда вы «вызовете» класс. Вызов класса означает создание его экземпляра" и является в общем-то чушью
инит это не конструктор
ну и так далее. Зачем это было написано? Это даже не плохо процитированный учебник, это записки студента на полях. При желании можно было бы написать полезную статью про декораторы. Как сделать универсальный декоратор для которого не обязательны скобки при отсутствии параметров, как сделать декоратор с состоянием, как совместно использовать мощь декораторов и дескрипторов, например.
Как это работает, более-менее понятно, а как это программировать то? Допустим, у меня есть веб-сервер на python + Django. Он состоит из набора view, каждая вьюшка - функция, казалось бы - вот оно. Но есть же еще, скажем, ОРМ. Для инициализации моделей, построения дерева отношений и пр. требуется время. В обычном "серверном" сценарии мы жертвуем несколькими секундами "на разогрев" на этапе импорта, один раз для процесса. Далее обработка каждого входящего запроса - ну то есть каждого вызова функции - эта работа не нужна, все уже в памяти процесса. Правильно ли я понимаю, что с модными молодежными безсерверными технологиями мне прийдется вручную строить SQL запросы в стиле PHP пятнадцатилетней давности?
Ответ на этот вопрос в статье, к сожалению, не прозвучал. Так как он, реален или нет?
Копирайтер написал статью, получил за это денежку, молодец. Редактор статью почитал, покритиковал, отредактировал - поработал одним словом, получил свою денежку - тоже молодец. Маркетолог, добавил какие-то одному ему ведомые цифры в квартальный отчет - его полезность и эффективность налицо. Фирма которая им всем платит напомнила читателям о своем существовании и, вероятно, увеличит свои доходы на какой-то процент, директор купит любовнице новый мерседес. Все счастливы! Вот я эту статью прочитал. И казалось бы - нечего возразить, не с чем спорить. Но дала ли мне эта статья какое-то новое знание, новую точку зрения или повод о чем-то задуматься? Да... нет. Так-то разобраться, здесь же капитаноочевидные вещи. Ну надо же идиотом быть, чтобы прийти на собеседование как разработчик и забыть спросить, какой же стек технологий твой потенциальный работодатель использует. Ну или на собеседовании просить показать задачи в бэклоге (вы в своем уме??). В общем, друзья, производите вы никому не нужную туфту в промышленных масштабах.
Я глубочайше уверен, что были десятки исследований (говоря о десятках, автор дает ссылку на единственную статью, из которой даже не вполне ясны условия эксперимента), которые показали противоположные результаты, или не показали никаких результатов. Или таких исследований не было? Или они не известны автору? Или они известны автору, но он сознательно о них не упоминает? Как-то это, коллеги, всё очень желтушно выглядит. Я ни коим образом не профессионал, но когда вижу что-то наподобие «ускоряет вывод поврежденных клеток», мне кажется вот ещё чуть-чуть и начнутся глупости про шлаки, очишения организма и уринотерапию. При чём, если поискать, то уверен, что есть десятки и сотни исследований, показывающих благотворное влияние упаренной урины на организм.
потом они уволили еще 250 человек потому что
По-моему они сами себя активно топят и гугл здесь вовсе не при чём
Это технология, она проходит проверку временем или не проходит. Полезные идеи приживаются, терминология меняется, подходы меняются. Да сам автор тогда в 90-х вряд-ли мог вообразить во что вревратится интернет в 2020-х.
Вот эта статья, мне кажется, в подобной же риторике написана. «Вы не правильно используете». Да идите вы к чёрту, господа, как надо, так и используем.