bioroot

Евгений, про Selenium у них собственно в первой же строчке написано. На мой взгляд Selenium просто стандарт де-факто и привычный инструмент для тестировщиков. По этой причине его обычно используют не глядя на задачу (собственно, первый ответ к этому вопросу). При этом для целей "протыкать сайт" он явно избыточен. Cypress как раз хорош простотой и понятностью. Даже новичку в js с ним работать комфортно. И показать результат тестов заказчику, программисту, верстальщику очень просто. Можно визуально посмотреть последовательность действий и к чему они привели.

В сухом остатке, если вы пишите супер-проект с high-load, PWA и прочими хайповыми словами, то Cypress - не лучший выбор. Но если вы пишите обычный магазин, сайт-визитку, или ещё что-то такое, что входит в 95% проектов в интернете, то на Cypress по крайней мере стоит посмотреть.

Подробности бы и правда не помешали. Пока это выглядит как что-то типа Strategy, когда у вас есть один класс с некой общей логикой и куча разных реализаций частностей. Но суть проблемы не ясна, т.к. если вы можете административно указать разработчикам как и что писать, то можете получить любые имена классов и любых предков. Если вам нравится, то пусть называют все свои классы Scheme и наследуются от некого BaseScheme. Пока вы не расскажете как вы всё это собираетесь использовать я не вижу никаких препятствий.

Добавлю свои пять копеек. Мода может и уходит (вообще js слишком специфичный, чтобы быть модным долго), но направление движения у js-сообщества очень правильное. Собственно, мода и пошла с того, что один язык используется для фронтэнда и бэкэнда. Дальше хочется видеть максимальное повторное использование кода и на клиенте и на сервере, куда гребёт Meteor, а ещё лучше её же использовать и в мобильных приложениях, куда гребёт Appcelerator. Не кидайтесь помидорами, знаю что оба сыроваты, бажны и глючны. Но сама идея отличная. Если некий продукт позволит использовать одну логику на сервере, в браузере и на мобильных - это будет очень круто. И пока js-сообщество не перестанет барахтаться в этом направлении я бы не торопился хоронить js в целом и node.js в частности.

И не должно. Я имел в виду, что у вас в $_POST["type"] ничего не записано.

Из application ничего и не возвращается, потому и undefined. Можно вписать в него return ниже ajax, но это гиблое дело. Либо дёргайте внешнюю функцию из success, либо учитесь promise'ам.

А когда вы вторую функцию вызываете и как? Обычно когда возникают подобные проблемы это значит что ajax-запрос ещё не отработал. Если без претензий по качеству кода и просто "чтобы работало" - вызывайте вторую функцию изнутри success. Т.е. напишите там function (data) { drawFunction(data); }

Что вы откуда и куда возвращаете? Где undefined? Если запрос прошёл, то метод success будет честно дёрнут. Какого ещё эффекта вы ожидаете и куда вставляете console.log? В теле success он конечно отрисует данные. Но вне него вы данные просто не пробрасываете.

Ну это на любителя. Я-то считаю что среднестатистическому программисту легче всего разбирать код либо на Java, либо на C#. Да и Unity это не только C#. Там скорее остальные плюсы перевешивают, а язык просто как вменяемое требование, на которое вполне можно согласиться. По крайней мере в данной конкретной ситуации. Если знать что конкретно нужно, то можно и на Go. Но я, например, знаю людей, которые второй год пилят нечто под Android/iOS/web, которое можно было запилить месяца за 4 на Unity и посмотреть, взлетит или нет. В конечном итоге зависит от цели, но я считаю, что скорость разработки экономически важнее переоптимизированного кода.

Ну как сказать плоха... Просто в моём понимании несколько странновато говорить о крупных проектах в таком контексте. Обычно там используется несколько больше одной технологии. Т.е. какие-нибудь сервисы на Erlang/Java/C для работы с большими объёмами данных (статистика и т.п.), какой-нибудь Couchbase и подобные масштабируемые NoSQL-решения для быстрого доступа к пользовательским данным, плюс нормальная СУБД с поддержкой транзакции для критичных (а-ля финансовых) операций, плюс очереди для запуска разных операций в фоновом режиме... Ну можно туда и Django вкорячить для отдачи главной страницы с надписью "Рады приветствовать вас на нашем сайте" и для задач типа "постучись к такому-то демону и отрисуй что он тебе отдаст". Можно и что-то другое вкорячить. Разницы нет. Но у меня язык не повернётся назвать подобного монстра "проектом на Django". Это проект из кучи-кучи технологий, одной из которых может являеться Django.

Не, это понятно. Что сделать-то надо? Просто очень не хочется разбивать создание и вызов функции на два этапа?

Почему интроверт?

Не поленился, прогнал обе функции по сто тысяч раз. Получилась разница в третьем знаке после запятой. Эка экономия. Интуитивно-понятно что с передачей по ссылке быстрее, но вот почему? Какой правильный ответ? Что-нибудь в духе «ПХП не приходится делать проверку расклеивать переменную на две или нет»?

А можно ещё примерную динамику? Т.е. приложение в таком-то жанре с ценой в районе стольких-то за такое-то время принесло столько-то денег? Естественно, можно просто порядки величин. Просто интересно есть ли резон туда лезть. Сколько там денег крутится? Понимаю что многое зависит от приложения, но было бы здорово почитать про какой-нибудь живой пример.