Почему 8? Это стереотип — наиболее продуктивно работать по 4 часа в день. Успеваешь больше и дольше остаешься свежим. Умные люди платят не за часы а за результат. Нет цели чтобы ты забембался — цель получить результат.
Ну а так — да, по-началу экономишь на себе. Я тоже раньше сидел на таком стуле — ничего, пережил.
Вот что значит уважение к возрасту. Т.е. чел. живет и знает что после 50 он не станет никому не нужным старым хрычом, а наоборот — его зарплата будет предметом зависти многих молодых. У нас же только и разговоры — а есть ли жизнь работа после 40.
в MVC оно тоже присутствует только логика страницы размазывается по разным классам
В MVC тратится время, чтобы переходить от View к нужному контроллеру (т.е. навигация в процессе разработки). А в Razor Pages все рядышком…
Совмещение данных и методов, которые с ними работают (т.е. объединение модели и контроллера в один класс) — имеет как плюсы так и минусы. В любом случае подход имеет право на жизнь. Главное что View — отдельно.
Нет, это довольно старая фича (известная как ASP.NET WebPages), просто её наконец-то вытащили на свет.
Совсем не то. В Razor Pages во View работа с моделью, основные методы (код) в отдельном C#-классе. Т.е. присутствует разделение представления и логики.
Основная претензия к тем же JSP, старому ASP, PHP (хотя PHP и другие проблемы, более серьзеные) — это мешанина из кода и разметки. В Razor Pages эта проблема решена.
в ходе регистрации которых в JIRA вновь уточняются приоритет и сроки реализации требований
Вот этот момен и является ключевым — кто и на основе какой методики указывает сроки. Чтобы сроки не срывать — их нужно правильно вычислить. Но кто это сможет сделать?
1. Если переложить на разработчика, то нарушается принцип интересов. Начинающий не понимает, что детали не видны издалека и поставит мало времени — потом его же будут наказывать за медленную работу (а работа может быть не медленной — просто нет навыков планирования). Если разработчик опытный — то ему не выгодно быть врагом себе и он выставит срок с большим запасом, понимая что многие детали проявятся в процессе работы.
Пример. Задача объективно решается день. Один оценил ее в 2 дня и выполнил за полтора дня — молодец. Второй оценил в 4 часа и выполнил за день. Кто из двух работал лучше? И какая методика проверки?
В теории можно дать одну и ту же задачу двум разработчикам и посмотреть кто выполнит быстрее. Но! Кроме скорости выполнения есть еще и качество — кто будет его оценивать?
2. Если оценивают не разработчики — то по какой методике? Метод функциональных точек? Что еще? Как оценить, не понимая деталей работы?
Чел. поделился своей историей достижения гармонии, может молодым полезно будет узнать. Почему так негативно восприняли? Зависть?
Просто не хочется видеть фрилансера успешным — в нашем представлении это чувак, работающий с утра до ночи за похлебку и тратящий 50% времени на согласования, которые не оплачиваются.
Сама идея долговечности мне нравится. Но конкретно по вашей программе — открыл и не очевидно как ее использовать, множество данных нужно вводить. По этому пока да, использовать ее может только автор.
Ну а так — да, по-началу экономишь на себе. Я тоже раньше сидел на таком стуле — ничего, пережил.
Динозавром или монстром, позвольте уточнить?
жизньработа после 40.Модель-контроллер в Razor Pages объединяет как данные, так и методы работы с ними. Ближе к классике ООП, но есть и свои минусы.
В MVC тратится время, чтобы переходить от View к нужному контроллеру (т.е. навигация в процессе разработки). А в Razor Pages все рядышком…
Совмещение данных и методов, которые с ними работают (т.е. объединение модели и контроллера в один класс) — имеет как плюсы так и минусы. В любом случае подход имеет право на жизнь. Главное что View — отдельно.
Совсем не то. В Razor Pages во View работа с моделью, основные методы (код) в отдельном C#-классе. Т.е. присутствует разделение представления и логики.
Основная претензия к тем же JSP, старому ASP, PHP (хотя PHP и другие проблемы, более серьзеные) — это мешанина из кода и разметки. В Razor Pages эта проблема решена.
Вот этот момен и является ключевым — кто и на основе какой методики указывает сроки. Чтобы сроки не срывать — их нужно правильно вычислить. Но кто это сможет сделать?
1. Если переложить на разработчика, то нарушается принцип интересов. Начинающий не понимает, что детали не видны издалека и поставит мало времени — потом его же будут наказывать за медленную работу (а работа может быть не медленной — просто нет навыков планирования). Если разработчик опытный — то ему не выгодно быть врагом себе и он выставит срок с большим запасом, понимая что многие детали проявятся в процессе работы.
Пример. Задача объективно решается день. Один оценил ее в 2 дня и выполнил за полтора дня — молодец. Второй оценил в 4 часа и выполнил за день. Кто из двух работал лучше? И какая методика проверки?
В теории можно дать одну и ту же задачу двум разработчикам и посмотреть кто выполнит быстрее. Но! Кроме скорости выполнения есть еще и качество — кто будет его оценивать?
2. Если оценивают не разработчики — то по какой методике? Метод функциональных точек? Что еще? Как оценить, не понимая деталей работы?
Это скорее исключение. Как правило требуется проводить в офисе 8 часов + 1 час перерыва тоже там.
Просто не хочется видеть фрилансера успешным — в нашем представлении это чувак, работающий с утра до ночи за похлебку и тратящий 50% времени на согласования, которые не оплачиваются.
Вот за это и не любят JS. Т.е. нужно в голове держать целый такой алгоритм из 8 пунктов, чтобы в отдельных случаях знать поведение кода.
Вангую замену this на однозначный self или что-то подобное. Как пришлось добавлять === и !==.
Видимо имелся в виду validator.w3.org
Сама идея долговечности мне нравится. Но конкретно по вашей программе — открыл и не очевидно как ее использовать, множество данных нужно вводить. По этому пока да, использовать ее может только автор.