Не до конца, видимо, понял зачем это нужно Вычисление будет в разы дольше нативного из-за парсинга, а запрограммировать приоритеты операторов можно только так же как в стандартной математике, иначе вы всех введете в заблуждение
Один проверяет цепочку прототипов, а другой смотрит что за тип у переменной. Так что вся статья это попытка отделить теплое от мягкого.
Зачем переводить примитивные вещи? Ну не можете свое написать, ну возьмите какой-нибудь интересную тему и сделайте исследование по теме. Разберитесь в вопросе и напишите свою статью. Пускай будет плохая и унылая, но зато своя.
Почему все просто рвутся набрать плюсов на переводах всякой фигни?
Цыганщина как правило оперирует абстрактными понятиями, которые ты просто так не проверишь. Типа "выпал из ресурса", а как обратно в ресурс сотрудника запихнуть не говорит, а если вдруг запихнул и не помогло, то значит не совет плохой, а запихнул не так. Еще как пример идут разговоры про всякие там обесценивания, и что выгоревший золотко, а кругом все дураки (ну как в статье примерно говорили).
А в статье же вам привели ссылку на исследования и дали вполне конкретные проверяемые вещи:)
Не граница, а грань. Это некоторый суффикс строки, который равен ее префиксу. Подробнее про их полезность вы можете прочитать в предыдущей статье:)
Вообще здесь не совсем классические грани, а грани префиксов. Они нужны для более жадных переносов. Т.Е. когда у нас не сходятся проверяемые символы, то мы не просто переносим индекс поиска, а к следующему вхождению подобного паттерна.
"!!" не оператор, а в два раза лучше -- два оператора:) А вообще не портите код, пишите Boolean, ===, просто запихивайте переменную в if, но не делайте !!
Аналитики вряд ли, да и не каждый тестировщик даже айтишник. Если тестировщий "ручной", то он просто читает бумажку и наживает кнопочки на экране. А если он фигарит автотесты на каком-нибудь ЯП, то тогда да.
Чтобы быть айтишником, то должендолго бодаться с чем-то айтишным, с конфигами там, с кодом, архитектуры там придумывать, связи между приложениями налаживать:)
Мемоизация - это простой, но мощный трюк, который может помочь ускорить наш код, особенно при работе с повторяющимися и тяжелыми вычислительными функциями.
Хоть бенчмарки бы приложены были, чтобы показать как фибоначчи себя ведет в одном случае или в другом, чтобы наглядно продемонстрировать прирост скорости. Ну или хотя бы количество вызовов орилинальной функции в одном случае и в другом. Надо же продемострировать результаты работы мемоизации наглядно. Очень сложно оценивать результаты подобных подходов не имея цифр перед глазами.
Программист пишет код. Не читает, не анализирует, не тестирует, не оптимизирует.
Программист чаще и больше читает код, нежели пишет. Именно поэтому важно код красиво оформить, протестировать и проанализировать прежде чем его передать другим, чтобы они могли больше писать и меньше тратить время на чтение.
Не до конца, видимо, понял зачем это нужно
Вычисление будет в разы дольше нативного из-за парсинга, а запрограммировать приоритеты операторов можно только так же как в стандартной математике, иначе вы всех введете в заблуждение
Так что вышел yetAnotherFramework
Вот он пошел в отставку, а в итоге переходит на важная должность в АП
Как бы радоваться все равно не получается
А теперь тема лекции: "Выгорание в IT и бизнес-планирование"
Простите, больше не буду
Товарищ говорит так, будто он самолично их поддерживает и при этом за GIF ему недоплачивают
Один проверяет цепочку прототипов, а другой смотрит что за тип у переменной. Так что вся статья это попытка отделить теплое от мягкого.
Зачем переводить примитивные вещи? Ну не можете свое написать, ну возьмите какой-нибудь интересную тему и сделайте исследование по теме. Разберитесь в вопросе и напишите свою статью. Пускай будет плохая и унылая, но зато своя.
Почему все просто рвутся набрать плюсов на переводах всякой фигни?
Цыганщина как правило оперирует абстрактными понятиями, которые ты просто так не проверишь. Типа "выпал из ресурса", а как обратно в ресурс сотрудника запихнуть не говорит, а если вдруг запихнул и не помогло, то значит не совет плохой, а запихнул не так. Еще как пример идут разговоры про всякие там обесценивания, и что выгоревший золотко, а кругом все дураки (ну как в статье примерно говорили).
А в статье же вам привели ссылку на исследования и дали вполне конкретные проверяемые вещи:)
Успехов в начинании:)
Не граница, а грань. Это некоторый суффикс строки, который равен ее префиксу. Подробнее про их полезность вы можете прочитать в предыдущей статье:)
Вообще здесь не совсем классические грани, а грани префиксов. Они нужны для более жадных переносов. Т.Е. когда у нас не сходятся проверяемые символы, то мы не просто переносим индекс поиска, а к следующему вхождению подобного паттерна.
Для расчета prefixBorders
С помощью borderPositions во вкладке "Код получения массива сдвигов" вы можете посмотреть алгоритм
Нет в JS оператора "!!".
"!!" не оператор, а в два раза лучше -- два оператора:)
А вообще не портите код, пишите Boolean, ===, просто запихивайте переменную в if, но не делайте !!
Аналитики вряд ли, да и не каждый тестировщик даже айтишник. Если тестировщий "ручной", то он просто читает бумажку и наживает кнопочки на экране. А если он фигарит автотесты на каком-нибудь ЯП, то тогда да.
Чтобы быть айтишником, то должендолго бодаться с чем-то айтишным, с конфигами там, с кодом, архитектуры там придумывать, связи между приложениями налаживать:)
Солипизм все описавает как результат жизнидеятельности мозга, а значит все гуманитарное, техничского ничего нет. Но только если вы солипсист:)
По совместительству гармошка
Решил свою хотелку добавить:)
А то неловко, если все будут видеть, как большой брат подсматривает за тобой
Безопасность это хорошо, но вот когда тебе платят много денег, это еще лучше
Но особенно круто -- комментарий "конструктор"
Хоть бенчмарки бы приложены были, чтобы показать как фибоначчи себя ведет в одном случае или в другом, чтобы наглядно продемонстрировать прирост скорости. Ну или хотя бы количество вызовов орилинальной функции в одном случае и в другом.
Надо же продемострировать результаты работы мемоизации наглядно.
Очень сложно оценивать результаты подобных подходов не имея цифр перед глазами.
Еще про утечки памяти пожно было бы упомянуть:)
Ну надеюсь, что мы к такому не придём. А то как же мне страшно будет жить в мире, где половина может только слушать, а половина только говорить:)
У нас в компании это требование есть на определённом грейде. Типа, раз новенький побегай пока, а потом это и тебя коснется
Программист чаще и больше читает код, нежели пишет. Именно поэтому важно код красиво оформить, протестировать и проанализировать прежде чем его передать другим, чтобы они могли больше писать и меньше тратить время на чтение.