В вашем коде n*log(n), а можно действительно за линейную сложность, по сути sort суффикса новый это revers его, получает n на поиск суффикса, потом binary search на элемент который надо поменять(log (n)) и reverse (n/2) получается O(n)
Хватит 55к(в год до вычета) на вполне хорошую жизнь на двоих с ребенком в Берлине(летая на выходных 1 раз в месяц, плюс в месяц покупать по XBOX ONE S) это так чтоб понять, а так чем больше тем лучше
Я вроде на все вопросы ответил. Я не считаю, что линтеры, style guide, babel и т.д и т.п нужны всем проектам. Например, я пишу себе прогу для телевизора на electron, ну и зачем мне style guide и linter, мне важен результат, должно работать. Все эти штуки придуманы для того, чтобы интеграция новых членов в команду стоила как можно меньше и разработка была продуктивнее.
Best Practices нужны для того, чтобы писать красиво, понятно и однозначно.
Это предназначение Style Guide
Обычно подводные камни называют «особенности» языка.
Вот как пример статья habr.com/post/159313
Эти штуки есть в подавляющем числе IT команд, которые специализируются на разработке программ, сайтов, которые делаются всегда(или будут апгрейдится). А не веб сайты на заказ, где это нафиг никому не надо. Полностью не согласен с этим высказыванием, возможности языка надо просто изучать, потому что их всегда очень много, и надо постоянно поддерживать форму чтобы не забыть. Best Practices на то и Best Practices, они пишутся не того чтобы показать возможности языка, а для того чтобы обойти подводные камни
Причем тут 2018 года? Тут статья о возможностях языка, а не о том полезно это юзать или нет. Практически уверен, что какие нибудь веб студии или разработка сайтов под заказ, можно найти примеры использования в одном файле let, const, var.Но синтаксис и возможности это разные вещи, не кто не говорит, что возможности языка всегда делают хорошие вещи, но это не делает их бесполезными. Везде надо стараться использовать наиболее оптимальный инструмент для работы, но чтобы выбирать надо знать как можно больше возможностей.
Когда это простите синтаксис данный устарел? let, const это не замена var, они другое подразумевают, общего у них что это способы объявление переменных. Или когда IIFE, стали старым синтаксисом.
Эта статья предназначена, в основном, для начинающих программистов — для тех, кто, вроде бы, знаком с такими вещами, как замыкания и IIFE, но пока не особенно уверенно ими пользуется.
Данная статья вполне понятная для новичков, с примерами и на русском(пора смериться, что не все новички идут по книжкам или с первоисточников и документаций, но с опытом приходит все), они ж не написали делайте только так, они просто разобрали примеры. Я конечно согласен, что ru_vds иногда переводит, реально странные статьи, но все же они делают хороший вклад для развития новичков.
Поправьте если я ошибся, но мне кажется вы просто заменили HashMap в пару ключ значение и назвали это расширенных enum. Я просто не понимаю почему тогда нельзя объявить HashMap, где ключем будет один из enum значений, а значением набор code, text, color. Если же я неправильно понял, то можно описать требуемую enumа функциональность
Источник проблемы надуманный, по сути в статье мы сами создали источник проблем, и потом героически говорим так делать нельзя, можно было просто сразу источник не создавать. Источник проблемах в сторонних модулях, это уже гораздо интереснее. Но от всего не обезопасишься, по сути вам никто не мешает, выпустить модуль с "evil код", только будет ли кто им пользоваться.
Это предназначение Style Guide
Обычно подводные камни называют «особенности» языка.
Вот как пример статья habr.com/post/159313
Данная статья вполне понятная для новичков, с примерами и на русском(пора смериться, что не все новички идут по книжкам или с первоисточников и документаций, но с опытом приходит все), они ж не написали делайте только так, они просто разобрали примеры. Я конечно согласен, что ru_vds иногда переводит, реально странные статьи, но все же они делают хороший вклад для развития новичков.
Статья интересная, правда тоже хотелось бы больше узнать ваши рабочие обязанности.
PS Все жду когда ваша компания (N26) откроет frontend вакансии.
Это не статья о возможностях языка, это статья мы придумаем проблему, и будем говорить так делать нельзя.
Источник проблемы надуманный, по сути в статье мы сами создали источник проблем, и потом героически говорим так делать нельзя, можно было просто сразу источник не создавать. Источник проблемах в сторонних модулях, это уже гораздо интереснее. Но от всего не обезопасишься, по сути вам никто не мешает, выпустить модуль с "evil код", только будет ли кто им пользоваться.
И как вы от этого обезопаситесь? Проблема надумана полностью. Статью можно заменить одним предложением: "Чтобы говна не было, не испражняйтесь"
А где про это написано?
Конечная идея образования научить делать так чтоб работало и правильно, а не научить писать самим сортировку.
Я правильно понял, что данные с api запрашивать выгоднее всего на
created(), а неmounted()?