Сторибук и редакс девтулз хорошие инструменты. Плюс еще redux-promise-middleware-times можно использовать в девсборке для замеров скорости. Остальное уже кажется вторичным
Да и вообще, почему бы тем же движкам не выпустить свои инструменты для оптимизации?
Например, какие-то особо важные участки помечать специальным комментарием, а не какой-то конструкцией
Проблема ( как минимум с вебом ) это то что он еще не готов к такому бурному росту/изменению. Берешь какой-нибудь проект, который начинался в 2010, когда еще не было всяких es6, когда стандарты не выпускались каждый год и там дремучий древний лес. Как-то обновлять это — легче переписать с самого начала. Возможно, со временем, если скорость изменений языка/стандартов будет сохранятся, будут придуманы инструменты, для более безболезненного перехода на новые фичи языка.
Ну и да, какие-то монструозные проекты по определению столкнутся с тем, что в какой-то момент масштабировать их будет невозможно, просто из-за количества кода. И тут тоже нужно думать и искать новые подходы/архитектуру. Модульность — как хорошее начало, когда ты можешь взять и переписать один конкретный модуль и в идеале остальной проект даже не заметит это.
Не давно проходил собеседование в Яндекс на разработчика интерфейсов. Собеседованием остался доволен, на первом этапе спрашивали солянку из html, css и особенностей javascript, ничего сверхъестественного и заковыристого. На следующем этапе было 4 интервью, которые были в виде практических задач. Совсем чуть-чуть теории спрашивали, а потом решали задачи. Считаю это самым правильным вариантом. Кандидат прекрасно может знать структуры данных, крутые алгоритмы и прочие теоретические вещи, но какой в этом толк, если он не может применить их на практике. Конкретные задачи как раз помогают выяснить, что умеет и знает кандидат. Как он подходит к решению проблемы, какие алгоритмы и структуры данных использует. Ведь в итоге именно за этим и ищут человека, что бы он решал конкретно поставленные задачи, а не хвастался, что знает все алгоритмы обхода графа
В других языках не так что ли? Все эти компиляторы, SDK конфигурируются одной кнопкой, что даже ребенок может справиться с этим?
Предугадать абсолютно все желания пользователей нельзя, поэтому простые проекты да, делают без огромных конфигов, но это не значит, что должны быть только "простые" проекты. Проекты бывают разные, в том числе и сложные, которые в любом случае требуют доп настроек
Может я в маленьком городе живу, но ни разу не встречал на улице человека, который бы шел и ел. А места где продается фастфуд обычно оснащены местами, где этот фастфуд можно употребить, следовательно, к чему так зацикливаться на то, что бы еду можно было именно есть на ходу/в спешке. А если нет, то все сводится к обычной столовой, которая чуть более мобильна
Если я правильно понял задание с массивом, то нам нужно просто посчитать индексы значений, которые меньше k, получим массив (пример) [0, 1, 3, 4], а потом пройдем циклом по элементам и если следующий индекс больше предыдущего на 2 и больше, значит нужна перестановка.
Код на js
const array = [2, 7, 9, 5, 8, 7, 4]
const k = 5
const groupNearK = function (arr, k) {
const length = arr.length
const idx = []
let moveCount = 0
for(let i = 0; i < length; i++) {
if(arr[i] <= k) idx.push(i)
}
for(let i = 1; i < idx.length; i++) {
if((idx[i] - idx[i - 1]) > 1) moveCount++
}
return moveCount
}
console.log(groupNearK(array, k))
Решение за один цикл
const array = [2, 1, 5, 6, 3]
const k = 3
const groupNearK = function (arr, k) {
const length = arr.length
let moveCount = 0
let lastIndex = -1
for(let i = 0; i < length; i++) {
if(arr[i] <= k) {
if(lastIndex >= 0 && (i - lastIndex) > 1) {
moveCount++
}
lastIndex = i
}
}
return moveCount
}
console.log(groupNearK(array, k))
Вам еще не надоело хаить инструменты? Тут ведь все сводиться к делу вкуса: кто-то любит низкоуровневый Redux, где ты контролируешь весь поток данных, кто-то любит абстракции и магию, не задумываюсь о реализации всего этого. Но с чего это ваши личные предпочтения вдруг делают %инструмент_нейм% ужасным, неэффективным и вообще использование его становится моветон. Есть же альтернативы, так используйте их, зачем писать эти статьи? Я как новичок из них ничего не получу, так как легко могу найти статьи за и против любого инструмента. Все равно придется пробовать самому.
Кому-то нравится электродрель, кому-то молоток и гвозди, а кому-то легче нанять рабочих и вообще не париться.
Отдельных верстальщиков нет, точнее есть, но они в других проектах, а там уже не известно используют они React или нет. На нашем проекте вставал вопрос о разделении на верстальщика и разработчика фронта, но потом поняли, что это избыточно.
Какая-то реклама собственного фреймворка, на основе унижения React-а.
Участвую в проекте разработки CRM, пишем на React-е, есть огромная библиотека простых виджетов/ui-компонентов, которые используются/переиспользуются вполне благополучно. Да, тем кто раньше писал только ООП сложно поменять парадигму и перейти на функциональных подход к компонентам, поэтому все еще используют наследование и перегрузку методов, вместо HOC, но это лечится)
Я для решения проблемы дублирования редьюсеров использовал один редьюсер, который хранит в себе несколько стейтов, которые могут динамически создаваться и обращаться к ним можно по имени
C девтулзом хорошо дружит, потому что всегда можно посмотреть, какое имя передается в payload и тем самым понять, какой именно стейт в редьюсере будет изменен
Звучит как какое-то будущее, где приложения меняются визуально в зависимости от внешних факторов: утром цвета яркие, сочные, что бы взбодрить меня, ближе к вечеру становятся нейтральными, что бы глаза не уставали и т.д. Пусть еще анализируют элементы по которым я чаще всего кликаю/тапаю что бы располагать их ближе друг к другу или более оптимально. Вообще тут много и долго можно фантазировать и идея действительно интересная
Сторибук и редакс девтулз хорошие инструменты. Плюс еще redux-promise-middleware-times можно использовать в девсборке для замеров скорости. Остальное уже кажется вторичным
Да и вообще, почему бы тем же движкам не выпустить свои инструменты для оптимизации?
Например, какие-то особо важные участки помечать специальным комментарием, а не какой-то конструкцией
Интересно, что есть такого у
Optimize.js
, чего нет у движков браузера, если первый может понимать, когда нужно оптимизировать функцию, а вторые нет?Проблема ( как минимум с вебом ) это то что он еще не готов к такому бурному росту/изменению. Берешь какой-нибудь проект, который начинался в 2010, когда еще не было всяких
es6
, когда стандарты не выпускались каждый год и там дремучий древний лес. Как-то обновлять это — легче переписать с самого начала. Возможно, со временем, если скорость изменений языка/стандартов будет сохранятся, будут придуманы инструменты, для более безболезненного перехода на новые фичи языка.Ну и да, какие-то монструозные проекты по определению столкнутся с тем, что в какой-то момент масштабировать их будет невозможно, просто из-за количества кода. И тут тоже нужно думать и искать новые подходы/архитектуру. Модульность — как хорошее начало, когда ты можешь взять и переписать один конкретный модуль и в идеале остальной проект даже не заметит это.
Ничего не мог с собой поделать, но все время читал HOC по-русски)
На момент написания комментария расклад такой: 13.5% — "да", 82% — "нет", остальные не определились. Ну, хоть какое-то, но движение вперед есть)
Не давно проходил собеседование в Яндекс на разработчика интерфейсов. Собеседованием остался доволен, на первом этапе спрашивали солянку из html, css и особенностей javascript, ничего сверхъестественного и заковыристого. На следующем этапе было 4 интервью, которые были в виде практических задач. Совсем чуть-чуть теории спрашивали, а потом решали задачи. Считаю это самым правильным вариантом. Кандидат прекрасно может знать структуры данных, крутые алгоритмы и прочие теоретические вещи, но какой в этом толк, если он не может применить их на практике. Конкретные задачи как раз помогают выяснить, что умеет и знает кандидат. Как он подходит к решению проблемы, какие алгоритмы и структуры данных использует. Ведь в итоге именно за этим и ищут человека, что бы он решал конкретно поставленные задачи, а не хвастался, что знает все алгоритмы обхода графа
В других языках не так что ли? Все эти компиляторы, SDK конфигурируются одной кнопкой, что даже ребенок может справиться с этим?
Предугадать абсолютно все желания пользователей нельзя, поэтому простые проекты да, делают без огромных конфигов, но это не значит, что должны быть только "простые" проекты. Проекты бывают разные, в том числе и сложные, которые в любом случае требуют доп настроек
webpack
двигается в сторону полноценногоSDK
для веб приложенийЕсли я правильно понял задание с массивом, то нам нужно просто посчитать индексы значений, которые меньше k, получим массив (пример) [0, 1, 3, 4], а потом пройдем циклом по элементам и если следующий индекс больше предыдущего на 2 и больше, значит нужна перестановка.
Решается в один цикл
Пример с
React
иstate
в первом пункте не совсем правильный. Ошибкой будеттак как явно не указан
state
, а по умолчанию он равенnull
Backbone.js
еще жив?Вам еще не надоело хаить инструменты? Тут ведь все сводиться к делу вкуса: кто-то любит низкоуровневый
Redux
, где ты контролируешь весь поток данных, кто-то любит абстракции и магию, не задумываюсь о реализации всего этого. Но с чего это ваши личные предпочтения вдруг делают %инструмент_нейм% ужасным, неэффективным и вообще использование его становится моветон. Есть же альтернативы, так используйте их, зачем писать эти статьи? Я как новичок из них ничего не получу, так как легко могу найти статьи за и против любого инструмента. Все равно придется пробовать самому.Кому-то нравится электродрель, кому-то молоток и гвозди, а кому-то легче нанять рабочих и вообще не париться.
Отдельных верстальщиков нет, точнее есть, но они в других проектах, а там уже не известно используют они
React
или нет. На нашем проекте вставал вопрос о разделении на верстальщика и разработчика фронта, но потом поняли, что это избыточно.Какая-то реклама собственного фреймворка, на основе унижения
React-а
.Участвую в проекте разработки CRM, пишем на
React-е
, есть огромная библиотека простых виджетов/ui-компонентов, которые используются/переиспользуются вполне благополучно. Да, тем кто раньше писал только ООП сложно поменять парадигму и перейти на функциональных подход к компонентам, поэтому все еще используют наследование и перегрузку методов, вместоHOC
, но это лечится)Я для решения проблемы дублирования редьюсеров использовал один редьюсер, который хранит в себе несколько стейтов, которые могут динамически создаваться и обращаться к ним можно по имени
C девтулзом хорошо дружит, потому что всегда можно посмотреть, какое имя передается в
payload
и тем самым понять, какой именно стейт в редьюсере будет измененТеперь у меня есть отговорка перед девушками)