Задать вопрос
  • Можно ли писать бэк на C#, а фронт на React и есть ли в этом смысл?

    @Lexans
    Проблема сайтов на c# в том, что почти нет нормальных хостингов для него в отличии от php. А те что есть и поддерживают net core. я использовать не смог - при публикации (обновлении) сайта везде вылезала ошибка, типа нельзя заменить исполняемый файл, поддержка ничем не помогла. Таким образом сайт придется хостить на собственном впс на windows server, что довольно дорого.
    Так что попробуй опубликовать и обновить хотя бы простенький сайт на таких хостингах как fozzy и smarterasp
    Ответ написан
    2 комментария
  • Что такое end-to-end тестирование?

    pi314
    @pi314
    Президент Солнечной системы и окрестностей
    Понятие еnd-to-end обозначает всего-навсего классификацию тестов по уровню, на котором тестируется система, и, само по себе, ничего не говорит ни о том, какие конкретно должны быть эти тесты, ни о том, какую роль они играют в общей стратегии обеспечения/проверки качества и, также, не является методикой тестирования. (Методика - это совсем другое понятие.)

    Для понимания сути этого понятия хорошо сравнить его с модульным ("нижний" уровень) и интеграционным ("средний") тестированием на каком-нибудь конкретном примере. Давайте рассмотрим некий сферический webshop в вакууме. Предположим, в нем есть 50 классов и для большинства из них написаны модульные тесты. Они проверяют исключительно функционал конкретного модуля (чаще всего, класса), т.е. тот, что зависит только от самого модуля и ни от чего чего более. Потом есть интеграционные тесты. Они проверяют корректность работы отдельных "модулей", если их собрать вместе согласно архитектурe. Например, работает ли правильно "Корзина", состоящая, в свою очередь, из 10 классов (предварительно проверенных модульными тестами), или "Корзина", подключенная к "Вебморде" и т.д. Где-то повыше в этой иерархии есть такие интеграционные тесты, которые проверяют конкретный функционал всей системы. Например, отправляется ли юзеру мейлом копия оплаченного заказа...

    И вот тут начинается самое интересное для понимания того, что такое end-to-end тестирование! Можно представить себе тест, проверяющий, что соответствующий мейл генерируется и сбрасывается SMTP серверу. Если SMTP сервер не рассматривать, как часть разрабатываемой системы, то этот тест вполне можно назвать end-to-end тестом (послали кучку HTTP запросов через "Вебморду" и проверили сброс мыла на SMTP - все зашибись!). Однако, если настройки и эксплуатация SMTP сервера - часть проекта (например, заказана разработка webshop "под ключ"), может оказаться, что это мыло будет отфильтровано каким-нибудь спам-фильтром, превысит лимит почтового ящика пользователя... короче, не дойдет до него. Тогда этот же самый тест уже нельзя считать end-to-end, а нужно бы было написать тест, проверяющий приход мыла в POP3/IMAP ящик. (Опять же, если это действительно нужно! Ибо, в зависимости от конкретных функциональных и нефункциональных требований, архитектор и QA инженер вполне могут найти возможность обеспечить адекватный контроль качества и без такого теста.)

    Таким образом, end-to-end тесты, это такие интеграционные тесты, которые воздействуют на систему через ее самые внешние интерфейсы и проверяют ожидаемую реакцию системы через эти же интерфейсы. Почему именно интеграционные? Потому, что это единственное, что можно о них сказать наверняка: они по определению не могут быть модульными тестами. А все остальное: являются ли они одновременно приемочными, нагрузочными или еще какими - зависит только от общих плана/стратегии тестирования и той роли, которые эти тесты в них играют.
    Ответ написан
    Комментировать
  • Как развить абстрактное мышление?

    dollar
    @dollar
    Делай добро и бросай его в воду.
    Это язык логики. Изучайте логику. Абстрактная модель точно описывает явление, а конкретный пример может не учитывать нюансы.

    Например: смотри, где я иду, иди за мной - это пример. А абстрактно будет звучать: переходить улицу можно только по зебре.
    Ответ написан
    1 комментарий
  • Как правильно вкатиться в разработку игр?

    dollar
    @dollar
    Делай добро и бросай его в воду.
    У вас, судя по всему, очень хороший бекграунд с учетом возраста и статуса школьника. Вообще наличие головы на плечах очень важно в геймдеве, потому что цена каждой ошибки умножается на количество фанатов игры. Ну и если подписывать контракт на миллион долларов (это еще мало), важно его не просрать. Так что хорошие оценки по всем предметам (а не только по точным) - залог успеха в будущем, даже если кажется или если вам говорят, что какие-то предметы не пригодятся.

    Однако вы, похоже, не совсем понимаете, что означает "заниматься геймдевом". Это примерно, как строить ракету или космический корабль. Конечно, если это не змейка или пятнашки. То есть свой велосипед или самокат вы сможете собрать из говна и палок, но продать такое не получится. А вот чтобы сделать что-то стоящее, хотя бы разработать автомобиль, нужно уже конкретно в автомеханику, да и то там уже куча моментов, которые один человек не осилит: устройство двигателя, аэродинамика и удобство салона - это абсолютно разные сферы знаний. Добавьте к этому маркетинг и технологии производства, и станет очевидно, что одному человеку такую задачу не решить.

    Также и с играми. Попробуйте ради прикола написать 2-3 предложения (не больше) описания игры в Стиме (или в мобильном сторе) для пользователей, чтобы в них содержалось самое главное об игре, чтобы пользователи заинтересовались ей. От этого зависит, будут ли люди скачивать/покупать игру, или же будут проходить мимо. Думаете, это просто? А вы попробуйте зацепить свою аудиторию. Забыл сказать, аудиторию тоже выбрать нужно, и ответ "моя аудитория - весь мир", это ответ на двойку.

    Придумайте иконку игры. Казалось бы, просто? Но у специалиста может уйти до 2 недель, если не больше, с учетом А/B тестирования, привлечения экспертов для оценки, собственно самих художников, чтобы ее нарисовать. Хотя я не спорю, иконка, сделанная на коленке за 10 минут, может быть самой удачной, но это уже лотерея, никто не запрещает испытывать судьбу на прочность, это дешево, просто шансы на успех стремятся к нулю.

    Процесса разработки самой игры я сейчас даже касаться не буду.

    А вот что вам важно знать, как мне кажется, так это то, что в геймдеве есть разные роли (профессии). Нельзя быть просто разработчиком игр. Ну, точнее, можно, но так говорят о людях, про которых ничего не известно, кроме того, что они имеют какое-то отношение к геймдеву. На самом деле человек выполняет какую-то специфическую роль в разработке. В небольших (инди) командах в одном человеке может совмещаться несколько ролей, но всё равно нынче (в 2019) никто не делает игры в одиночку. Поэтому изучите, какие есть роли, и определитесь, что именно вы хотите делать в разработке, а дальше можно будет искать или собирать команду, со всеми вытекающими сложностями командной разработки. После этого можно будет сказать, как вкатиться в разработку игр.

    Например, в дополнение к классическим художникам и программистам есть такие роли, как геймдизайнер, пм (project manager), продюсер, QA, дизайнер UI/UX, левел-дизайнер, моделлер, аниматор и т.д. Это далеко не все. Соответственно, в крупном проекте будет несколько геймдизайнеров, продюсеров и т.д., то есть там за "роль" отвечает уже целый отдел, в каждом из которых свои более узкие специальности. Ну а в мелком (на 10 человек) у каждого будет по пачке ролей.

    P.S. На всякий случай напомню, что релиз игры - это не конец, это только начало. А то в моде заблуждение, что после релиза можно открыть карман для денег и больше ничего не делать. Так что если вы (и ваша команда) вопреки статистике всё же сможете сделать игру, которая кому-то нужна, то "веселье" на этом не закончится.
    Ответ написан
    Комментировать