Почему не поменяет, как раз наоборот. Так как автор собрал пакет, и написал что он это сделал как для обучения, так и для использования, то почему бы не разобраться с reflect-metadata. Понятно что велосипед, но очень полезный для опыта.
Была еще задача на комплементарность ДНК. Решение ниже
const inp = 'ACCGGGTTTT';
const out = 'AAAACCCGGT';
// A -> T
// C -> G
// set mirror
// replace A to T
// replace C to G
// replace T to A
// replace G to T
function dnaComplement(str) {
let newStr = '';
for (let i = str.length - 1; i >= 0; i--) {
let s = str[i];
if (s === 'A') {
newStr = newStr + 'T';
} else if (s === 'T') {
newStr = newStr + 'A';
} else if (s === 'C') {
newStr = newStr + 'G';
} else if (s === 'G') {
newStr = newStr + 'C';
}
}
return newStr;
}
let resp = dnaComplement(inp);
console.log('resp ->', resp);
console.log(out === resp ? 'Done' : 'Wrong');
Немного оффтопа
Однажды пригласили меня на собеседование в одну фирму на позицию Senior JS developer (дело было в Кракове, Польша). В начале поговорили о жизни и ни о чем. Плавно перешли к менеджменту и микроменеджменту. И вот один из собеседователей говорит — ну что размялись, давайте теперь сделаем техническое интервью. Ну ок, не вопрос, конечно. И тут парень открывает гугл! А мне был виден его монитор немного, так как за спиной у него стеклянная стена и я видел отражение. И начинает читать вопросы для собеседования по JS с гугла Карл! Ты же сеньора собеседуешь! Ну как же так?!
Нда… теперь эта компания в моем личном черном списке. Нельзя же так не уважать людей, которые к вам приходят.
Расскажу один случай из своей практики. Был лидом на одном проекте/стартапе. Проект был «запущен» до меня. Проблем в нем было вагон и маленькая тележка. После анализа был предложен план, что как улучшить/переписать итд. Далее почти дословно:
(Я — тим лид, З — заказчик он же менеджер)
Я: Так же в это время входят тесты, что бы протестировать и выявить потенциальные проблемы.
З: Какие на# тесты мы стартап и у меня нет бюджета на тесты.
Я: O_O
Прошло три месяца. За это время в команде трудилось два джуниора, два мидла и один сеньор (моем лице).
При первом тестировании фокус группой было выявлено 100500 багов. Думаю вы догадываетесь что сказал заказчик. Но я все же напишу.
«Мне сказали что вы классные девелоперы, а вы тупые дебилы! Вы не умеете писать код!». Надо ли добавлять, что с проекта я конечно же ушел.
Как вижу подобный код и реализацию — честно, плакать хочется. Ну вот реально вьехать с пол пинка вряд ли получится. Далее все что только можно суем в глобальный стор. Туда жа запихавают логику приложения. Вот попробуйте потом такое приложение оптимизировать. Разбить на слои, где с каждым слоем работала бы команда.
Почему не вынести бизнес логику получения и обработки данных в отдельные слои? Зачем все держать в сторе, если данные нужны только в одном месте? Как сделать что-то не завязываясь на redux?
В большинстве туториалов пишут о том, что это серебряная пуля, вот берем и радость. Как сказал один девелопер у меня в команде — «чувак, ты не понимаешь?! Это же React-way! Надо только так писать, так в мануалах пишут». Над… В общем, на практике, это просто добавляет проблем, нежели профита.
Что делаю у себя в проектах, это в первую очередь разделяю приложение на слои: бизнес логика, API, компоненты, Store.
— API это набор классов, где реализована коммуникация с сервером
— бизнес логика, слой где обрабатываются и подготавливаются данные
— компоненты, по содержат логику только для отрисовки интерфейса, максимально стараемся делать их независимыми, маленькими и тупыми.
— Store. В сторе держим только те данные, которые нужны нескольким компонентам в одно и тоже время на странице. К примеру, профиль пользователя. Имя пользователя покажем в хедере сайта, в навигационном меню и на странице профиля пользователя. Изменили имя, поменялось в трех точках.
Как видно из описания, нет проблем разделить работы между людьми. Не жестких привязок. В любой момент можно заменить слой на другую технологию, не переписывая все остальное.
Все в мире циклично. Сколько лет производители сражались у кого тоньше телефоны. И сейчас имея тонкие смарфоны, их легко держать в кармане рубашки или в заднем кармане джинс. Вспоминаю первые кирпичи от нокии с толщиной 10-12мм и более. И сейчас тонкие девайсы. Прогресс.
Но нет, все в мире повторяется и вот снова: привет «кирпич» я скучал за тобой.
Если серьезно подойди к вопросу, мне почему то представлялся виток прогресса со смартфонами, это когда смартфоны заменят полностью лептопы. Когда мощности хватит на то, что бы запускать тяжелые приложения. Когда ты приходишь в офис и кладешь смартфон на док-станцию и оживает большой монитор, клавиатура и мышка и ты полноценно работаешь.
В чем преимущества перед Express/Koa/Restify/Fastify + handlebars/mustache/nunjucks?
PS Несколько лет использовал ExtJS на проекте. Пока не отходишь от дефолтного пути, все более менее нормально. Тормознуто, но работает. Но если надо что-то, что выходит за рамки, начинается боль и страдания. Потому у меня немного предвзятое отношение к ExtJS. Поэтому хотелось бы услышать ответы. Спасибо.
А создать слой API с объектами и методами в них для получения/отправки данных, и в settings вынести «настройкой» версию API и списки url уже считается плохим тоном?
Не поймите не правильно, но сопровождать запутанный код всегда сложно. Я когда разрабатываю приложение, то стараюсь к минимуму свести связанность. И конкретно для API делаю так, что бы можно было что либо поменять в настройках, не затрагивая приложение.
Ну почему сразу дерьмо. Я конечно не фанат TS. Но вот на проекте поставили условие — надо использовать TS. И я бы не сказал, что это так уж плохо. Да, иногда надо поизвращатся, что бы реализовать какую нибудь идею. Но так было только на первых порах, потом рука набивается. И что самое интересное, подумываю мигрировать свои личные проекты с JS на TS (пока только микросервисы).
Из плюсов хотелось бы выделить понимание что принимает функция, какие типы. Проверка кода на этапе разработки. Адэкватное поведение IDE.
И да, я уже говорил что не фанат TS. Но использование удобных инструментов таки приятно.
Хотел написать подобное, но вы точно описали мои мысли, респект!
От себя ниже добавлю, что большинство вопросов, которые я прочитал в статье — никогда не понадобятся в реале на фронте. Больше 10 лет я работаю с JS. Когда вижу такие вопросы, задаю один вопрос — где у вас это применяется?
PS и еще, всегда умалял вопрос по поводу сортировки. Типа отсортируйте массив (конечно не используя sort) по каким-то критериям или алгоритмам. Ну серьезно, вы действительно на проектах не сортируете массивы с помощью sort? Если так, то это же глупо.
У меня сделано разделение на «модель данных/валидация/простые компоненты/формы».
Каждый слой выполняет только свою возложенную на него задачу.
— модель данных — данные для формы, простой объект (ключ/значение)
— валидация — обеъект валидатор и набор валидаторов. Можно добавлять свои кастомные валидаторы. Валидатор работает асинхронно, потому можно и серверную валидацию использовать (проверка емаила итд).
— компоненты — простые и тупые. Инпут, кнопка итд. У инпутов добавлен так же вывод ошибок.
— Форма — просто связующий элемент. Валидирует модель данных. Итд.
При таком подходе можно использовать валидатор отдельно, даже не в реакте.
Компоненты можно использовать вне форм.
Код становится простым и гибким.
Немного оффтопа
Однажды пригласили меня на собеседование в одну фирму на позицию Senior JS developer (дело было в Кракове, Польша). В начале поговорили о жизни и ни о чем. Плавно перешли к менеджменту и микроменеджменту. И вот один из собеседователей говорит — ну что размялись, давайте теперь сделаем техническое интервью. Ну ок, не вопрос, конечно. И тут парень открывает гугл! А мне был виден его монитор немного, так как за спиной у него стеклянная стена и я видел отражение. И начинает читать вопросы для собеседования по JS с гугла Карл! Ты же сеньора собеседуешь! Ну как же так?!
Нда… теперь эта компания в моем личном черном списке. Нельзя же так не уважать людей, которые к вам приходят.
Расскажу один случай из своей практики. Был лидом на одном проекте/стартапе. Проект был «запущен» до меня. Проблем в нем было вагон и маленькая тележка. После анализа был предложен план, что как улучшить/переписать итд. Далее почти дословно:
(Я — тим лид, З — заказчик он же менеджер)
Я: Так же в это время входят тесты, что бы протестировать и выявить потенциальные проблемы.
З: Какие на# тесты мы стартап и у меня нет бюджета на тесты.
Я: O_O
Прошло три месяца. За это время в команде трудилось два джуниора, два мидла и один сеньор (моем лице).
При первом тестировании фокус группой было выявлено 100500 багов. Думаю вы догадываетесь что сказал заказчик. Но я все же напишу.
«Мне сказали что вы классные девелоперы, а вы тупые дебилы! Вы не умеете писать код!». Надо ли добавлять, что с проекта я конечно же ушел.
Почему не вынести бизнес логику получения и обработки данных в отдельные слои? Зачем все держать в сторе, если данные нужны только в одном месте? Как сделать что-то не завязываясь на redux?
В большинстве туториалов пишут о том, что это серебряная пуля, вот берем и радость. Как сказал один девелопер у меня в команде — «чувак, ты не понимаешь?! Это же React-way! Надо только так писать, так в мануалах пишут». Над… В общем, на практике, это просто добавляет проблем, нежели профита.
Что делаю у себя в проектах, это в первую очередь разделяю приложение на слои: бизнес логика, API, компоненты, Store.
— API это набор классов, где реализована коммуникация с сервером
— бизнес логика, слой где обрабатываются и подготавливаются данные
— компоненты, по содержат логику только для отрисовки интерфейса, максимально стараемся делать их независимыми, маленькими и тупыми.
— Store. В сторе держим только те данные, которые нужны нескольким компонентам в одно и тоже время на странице. К примеру, профиль пользователя. Имя пользователя покажем в хедере сайта, в навигационном меню и на странице профиля пользователя. Изменили имя, поменялось в трех точках.
Как видно из описания, нет проблем разделить работы между людьми. Не жестких привязок. В любой момент можно заменить слой на другую технологию, не переписывая все остальное.
К сожалению балом правят Android и iOS. И пока подвижек я не вижу. Предполагаю, что данное направление интересно только маленькой группе.
Все в мире циклично. Сколько лет производители сражались у кого тоньше телефоны. И сейчас имея тонкие смарфоны, их легко держать в кармане рубашки или в заднем кармане джинс. Вспоминаю первые кирпичи от нокии с толщиной 10-12мм и более. И сейчас тонкие девайсы. Прогресс.
Но нет, все в мире повторяется и вот снова: привет «кирпич» я скучал за тобой.
Если серьезно подойди к вопросу, мне почему то представлялся виток прогресса со смартфонами, это когда смартфоны заменят полностью лептопы. Когда мощности хватит на то, что бы запускать тяжелые приложения. Когда ты приходишь в офис и кладешь смартфон на док-станцию и оживает большой монитор, клавиатура и мышка и ты полноценно работаешь.
Увы… Плохой из меня аналитик.
PS Несколько лет использовал ExtJS на проекте. Пока не отходишь от дефолтного пути, все более менее нормально. Тормознуто, но работает. Но если надо что-то, что выходит за рамки, начинается боль и страдания. Потому у меня немного предвзятое отношение к ExtJS. Поэтому хотелось бы услышать ответы. Спасибо.
Не поймите не правильно, но сопровождать запутанный код всегда сложно. Я когда разрабатываю приложение, то стараюсь к минимуму свести связанность. И конкретно для API делаю так, что бы можно было что либо поменять в настройках, не затрагивая приложение.
Для Python использовал подобную схему со словарями.
Из плюсов хотелось бы выделить понимание что принимает функция, какие типы. Проверка кода на этапе разработки. Адэкватное поведение IDE.
И да, я уже говорил что не фанат TS. Но использование удобных инструментов таки приятно.
Пойду реализовывать подобное, поле ж не паханное!
От себя ниже добавлю, что большинство вопросов, которые я прочитал в статье — никогда не понадобятся в реале на фронте. Больше 10 лет я работаю с JS. Когда вижу такие вопросы, задаю один вопрос — где у вас это применяется?
PS и еще, всегда умалял вопрос по поводу сортировки. Типа отсортируйте массив (конечно не используя sort) по каким-то критериям или алгоритмам. Ну серьезно, вы действительно на проектах не сортируете массивы с помощью sort? Если так, то это же глупо.
У меня сделано разделение на «модель данных/валидация/простые компоненты/формы».
Каждый слой выполняет только свою возложенную на него задачу.
— модель данных — данные для формы, простой объект (ключ/значение)
— валидация — обеъект валидатор и набор валидаторов. Можно добавлять свои кастомные валидаторы. Валидатор работает асинхронно, потому можно и серверную валидацию использовать (проверка емаила итд).
— компоненты — простые и тупые. Инпут, кнопка итд. У инпутов добавлен так же вывод ошибок.
— Форма — просто связующий элемент. Валидирует модель данных. Итд.
При таком подходе можно использовать валидатор отдельно, даже не в реакте.
Компоненты можно использовать вне форм.
Код становится простым и гибким.