Можно, если программа ничего кроме как вывода 10 не должна делать, то пусть будет print(10); важен результат работы алгоритма. Если от алгоритма требуется более сложные действия чтобы выполнялись, то обычно это тестами всегда можно проверить. Проверку на то, как написан код с точки зрения best practice и прочего должен уже проверять ревьювер. Одну и ту же программу можно реализовать разными способами, проверка кода через регекспы - это сильное ограничивание студента в выборе инструментов для решения задачи, может быть для hello world'ов еще и сгодится, но по мере роста знаний у студентов они могут хотеть использовать разные конструкции и инструменты, и даже если изначально создатель задачи не предполагал что задачу могут решить подобным образом, все равно это может быть хороший код и отличное решение задачи.
нет, можно вообще ничего не разворачивать у себя, либо по минимуму — ну там постгрес поставть локально. Все через тесты проверять, потом деплоить на дев, потом уже на прод.
К нам иногда приходят новые разработчики в крупный энтерпрайз проект, который делается на государственные деньги. У этих бедолаг изначально глаза горят, а потом через несколько дней они понимают куда попали и огонь в глазах потухает и в них видно только отчаяние. Слава богу я больше не работаю в этом проекте, это был ужасный опыт.
Я согласен, поэтому и считаю, что если берешь на работу человека, где в основном нужно писать круды, то нужно и на собеседованиях спрашивать про работу сети, бд, инедексацию итд. Если же человек идет разрабатывать бд, то знать про сортировку полезно.
Я таки переборол себя и раскашелился, по началу было очень сложно на ней работать и очень не удобно, из-за чего сомневался в покупке, но потом через месяц уже привык более менее, есть некоторые нюансы при работе конечно, к примеру, не стоит пытаться дотянуться до всех клавиш не двигая кисти, в основном все клавиши досягаемы, но когда пытаешься использовать шорткаты то обычно надо немного кисть сдвинуть (и ничего страшного в этом я не вижу) я по началу пытался так дотягиваться, потом прочитал в доке что не надо так :) Ну и к слову, год уже пользуюсь и давно забыл уже про потраченные 350 баксов, зато эта клавиатура продолжает мне приносить огромное наслаждение и радость.
Работал на MS Nature, хорошая клавиатура, удобная, я давно освоил слепой набор текста, еще на плоских. Но вот сейчас у меня новая клавиатура — Kinessis Advantage 2, вот она более экстремальная в этом плане, на ней жутко не удобно набирать текст не правильными пальцами, а я привык набирать не правильно, т.к. тренажерами не пользовался никогда. В итоге за 2 неделе привык, еще через 2 недели привык к спец символам и кое каким шорт катам, правда некоторые шорт каты пришлось перемапить. Зато теперь это самая удобная клавиатура из всех что у меня были и значительно увеличилась точность набора текста.
То что у вас код со временем пишется гораздо-гораздо медленнее говорит лишь о плохом проектировании софта, тоже самое лего получить и с чистым JS. Сейчас то конечно да, jQuery уже не актуальный и вплоне хватает чистого ванильного JS, но в свое время он был просто жизненно необходим, чтобы нормально писать кроссбраузерные сайты, потому-что раньше браузеры не следовали стандартам и делали все по своему.
ООП ни плохо ни хорошо, надо уметь его правильно готовить, практика показывает, что у многих с этим очень плохо и ООП в данном случае может только навредить. Лично я для себя делаю так — для низкоуровнего АПИ очень хорошо ложится Data Oriented Design (тут как бонус еще и скорость), для высокоуровнего АПИ очень хорошо ложится ООП.
А вот еще и не плохая статья как готовить ООП: OOP is dead, long live OOP
Обычно — это просто разделение ответственностей, не обязательно лексический анализатор должен полностью пройтись по исходнику и сохранить все токены чтобы потом еще раз по токенам идти, можно делать это параллельно, скажем вызвал синтаксический анализатор метод lexer->getNextToken() лексер прочитал следующий токен и остановился, попутно сохранив offset. В итоге это просто инкапсуляция чтобы не думать о токенизации во время написания синтаксического анализатора.
Можно, если программа ничего кроме как вывода 10 не должна делать, то пусть будет print(10); важен результат работы алгоритма. Если от алгоритма требуется более сложные действия чтобы выполнялись, то обычно это тестами всегда можно проверить. Проверку на то, как написан код с точки зрения best practice и прочего должен уже проверять ревьювер. Одну и ту же программу можно реализовать разными способами, проверка кода через регекспы - это сильное ограничивание студента в выборе инструментов для решения задачи, может быть для hello world'ов еще и сгодится, но по мере роста знаний у студентов они могут хотеть использовать разные конструкции и инструменты, и даже если изначально создатель задачи не предполагал что задачу могут решить подобным образом, все равно это может быть хороший код и отличное решение задачи.
Какая разница, все равно странно, а еще странно что нужно еще и nginx настраивать и деплоить в облако.
Если уже работа того требует, то хочешь не хочешь, а ковыряться в системе придется.
А вот еще и не плохая статья как готовить ООП: OOP is dead, long live OOP
lexer->getNextToken()лексер прочитал следующий токен и остановился, попутно сохранивoffset. В итоге это просто инкапсуляция чтобы не думать о токенизации во время написания синтаксического анализатора.