Andchir, Это просто неопытный проверяющий - он предполагает что вы должны знать те условия которые у его в голове. А так же вместо того чтобы оценивать ваше решение, он вам пишет про свое - зачем это вам? чем оно лучше вашего? Что оно делает такого что не делает ваше? в чем отличие кроме того что ваше вы написали, а его - он написал?
Он написал конкретную задачу. Вы ее решили. То что он ждал чего-то другого, или того что вы будете сидеть и писать свою логику без использования существующих методов (а по факту и без использования простых операторов сравнения) - его проблема, он должен был это указать в задании.
Andchir, в данном конкретном случае в логике работы ни в чем, её нет.
Но есть в другом - лучше всегда писать === чем думать где надо === или == тоже подойдет, это упрощает и вашу работу и того кто будет этот код трогать после вас и уменьшает возможное количество будущих ошибок при изменении этого куска кода.
tmplts, инвойс это стандартная штука, наверняка люди работают по разному, но я не встречался с другими вариантами. Если вы работаете через сервис типа апворка, то исполнитель не будет вам отдельный инвойс делать - все для вас создает система, но что именно и в какой форме - не знаю.
нет. "на payoneer" вы ничего не заключаете - для вас это просто банк куда деньги переводить.
Заключаете сделку вы напрямую с исполнителем - составляете договор, он делает вам инвойсы, вы переводите деньги по каждому инвойсу.
вы можете заключить сделку "на upwork" если вас и исполнителя устроят комиссии (для исполнителя она начнется с 20% + всякие расходы на вывод денег, для вас - не знаю)
Интересно, как это вы в реакт-приложении создаете mysql-соединение?
Ну и вообще у меня сильное подозрение что текст ошибки вам должен подсказать многое, но вы же его не показываете.
Учитывая, что я, в перспективе, планирую переходить на один из их проектов, подобными вопросами я себе только наврежу. Неужели это не очевидно?
Нет, не очевидно, возможно у вас там змеиное гнездо где все друг друга говном поливают и ваши опасения действительно имеют под собой почву, но в любой нормальной конторе это действительно самый быстрый и эффективный способ.
Лучше прийти на проект хорошим спецом которого там же и подтянули, и которому сразу можно давать задачи, чем непонятным самоучкой, который все это время боялся подойти спросить, продвинулся куда меньше и потом выяснил что тут вообще все не так делают.
Как вы хотите чтобы люди здесь догадались о том что у вас за код, как вы вообще это делаете, где что хранится и так далее?
Пишите детали, код приведите, а еще лучше - ссылку на песочницу. Тогда быстрее ответ получите
Daria Motorina, "да что тут делать-то работы на полчаса, если я умел - сам бы давно сделал". Автор честно пишет "я не разработчик", ему простительно так ошибаться
еще как крайний вариант - выпилить весь код за исключением этих двух файлов и посмотреть что получилось прямо в билд. С большой вероятностью оно заработает где-то посередине выпила других модулей и комментирования разных импортов. Этот момент может тоже дать ответ что за проблема.
Держитесь, сейчас вам накидают на вентилятор за то что вы себя не уважаете, профессию предаете и из-за таких как вы, готовых работать за что-то неденежное, страна и отрасль в жопе.
Удачи, надеюсь найдете что ищете.
Ну лично я наоборот сейчас на фронте отхожу от ооп в сторону функциональных компонентов. Сходу вам расхожие шаблоны и варианты их использования не назову - я давно не теоретизировал на такие темы, это на мой взгляд актуально в основном для собеседований.
Для начала надо определиться что вы понимаете под ооп и какие шаблоны хотите применять? Если из книги банды четырех - то оттуда мало что подойдет просто потому что другой подход, язык и среда.
В реакте есть свои шаблоны, которые другие но применяются для тех же целей - HOC, render-свойства например. Можно и наследовать компоненты одни от других, но это уже считается антипаттерном.
Например композиция в компонентах - очень часто применяется, для переиспользования какой-то логики. Например можно валидатор выделить в отдельную сущность, пронаследовать от него два валидатора с несколько разной логикой (например для разного типа пользвателя) и затем передавать его в форму с которой работает этот пользователь.
Кому то это вполне себе шаблон и ооп, а кому-то нет.
Самое главное - знание хороших подходов и шаблонов, а главное проблем которые они призваны решать, позволяет видеть такие проблемные места и иметь в голове пару-тройку вариантов решения.
Если вы пишете хороший, переиспользуемый код, который легко читать и легко поддерживать - то наверняка уже используете набор разных шаблонов и подходов, возможно своих возможно почерпнутых откуда-то еще.
Мне правда интересно, откуда в твоем кругу общения столько гениев
Думаю работает принцип подобное к подобному. вы мой круг общения выяснили (выводы про "не ты" сделайте сами), теперь посмотрите на свой.
Crash, $50 нормальная ставка сеньора, это $6000 при 6 часовом рабочем дне. Такой работы достаточно много, сложность в том что таких профессионалов куда меньше и найти их сложнее. Как дорастете и отклоните свой первый оффер в $5000 за ненадобностью, вспомните этот тред, посмеетесь :) Главное не слушайте разных неудачников которые сами не смогли хоть немного вырасти и теперь комплексуют и утверждают что это не возможно никому.
До ставки $30 в час любой нормальный спец вырастает с нуля за пару лет. Естественно с текущим курсом надо идти на глобальный рынок.
Он написал конкретную задачу. Вы ее решили. То что он ждал чего-то другого, или того что вы будете сидеть и писать свою логику без использования существующих методов (а по факту и без использования простых операторов сравнения) - его проблема, он должен был это указать в задании.