А нет ли каких-нибудь примеров этих сложных проектов с миллионными оборотами? Просто вообще непонятно, если есть что то прям сложное, то это же по определению исключает готовые модули? И вот здесь все говорят о плюсах по сравнению с другими, а имеют ли сравнивающие реальное представление о чем-то другом? О безопасности там, гибкости?
Я так понимаю, что под администратором имеется ввиду работник, который наполняет новости на сайте и в принципе в объявлениях о работе говорится, что он ещё предлагает предложения по развитию, нанимает сторонних программистов по согласованию с начальством. По факту не знаю, что они там ещё делают, но сомневаюсь, что данный труд требует глубокой компетенции.
Вообще, не понимаю, что можно 9ть лет изучать в какой-нибудь cms. Года через два три разраб уже наверно должен начать разрабатывать дополнения, немного набить в этом руку, а куда дальше развиваться в рамках блоговой cms?
Ну, а как быть с переписыванием черновиков, зачеркиванием, надписыванием поверх зачёркнутого и вписыванием текста на полях? Оно конечно мило, но как-то совсем не практично
Ну, вы наверно на в стародавние времена, на стародавних версиях делали, с es3. С чего бы браузерам в хп его не поддерживать? А большая тройка как тогда? Это ж считай весь инет, если вместе с джиквери.
есть 2-3 часа в сутки на то, чтобы выполнять сложный умственный труд и этот "запас свежести"
Тут есть варианты. Когда запас истощается, и ты вот физически не можешь работать, сколько бы времени не заставлял себя пялиться в монитор, мозг тупо не соображает. Позависал полчасика в соц.сетях и фигась - мозг опять рулит и ты норм работаешь.
Хотя я вообще не программист, а дизайнер.
Дизайнер чего? Если веб, то до недавнего времени был не мыслим без фотошопа, и сейчас пикселеграфика без него не обходится, хотя есть варианты, становящиеся стандартом де факто. Дизайнеры вроде как зависимы от произовадительности машины и от софта, как вы справляетесь, имея оригинальные предпочтения в технике?
Антивирусы на ХП глючили году в 15-16м. Я свалил именно тогда и только потому, что пришлось работать с прогой с флеш-интерфейсом, которая подгружала комп. А потом от неё отказались, потому что она и клиентские компы подгружала в хлам, но полгода надо было побеждать это чудо за зарплату. Касперский вродь поддерживал, но у меня была установлена винда на неудачную файловую систему еще в школьничестве и работала, я не менял. Что до серфинга, то неизвестно, смогут ли барузеры с современным апи, всеми этими флексами да гридами например, работать на хп сейчас. Огнелись вот актуальный вредничает https://www.mozilla.org/en-US/firefox/95.0.2/system-requirements/
Я вот Масяню помню только по намедням. Толи инет был слаб, то-ли не было его ещё. Помню бесконечные форумы, долгую загрузку картинок, а вот чтобы оно подвисало или не подвисало - в памяти вообще не отложилось. Какие-то архивы с приколами смутно припоминаю,что они были,но не более. Вот здорово было бы посмотреть на документальный артефакт из античного веба, в котором вот эти вот флеши все испортили. "Здорово", потому что свидетельство для контраста о том, что все летало, у нас уже есть.
А можно как-нибудь ещё подробнее про сжирание внимания и ниши работы-творчества? У вас позиция оригинальная, так что не стесняйтесь рассказать как можно подробнее
Если класс непосредственно инжектит в себя какую-то зависимость и пользует её в своих методах, то какой тут должен быть "верхний код"? "правильная-не правильная" понятия изменяемые с течением времени и в предложенном примере одна зависимость все-таки отстала от другой и стала "неправильной".
Для юнит-тестов все 10 должны быть заглушками. Просто те 9 будут с совсем пустыми методами, а десятая с методами, которые либо делают что-то простое, либо сразу отдают какой-то результат - смотря что мы тестируем в целевом классе
Заглушка в тестах не должна складывать числа, не должна каким-либо образом дублировать поведение той реализации, которая будет подставлена в зависимость.
Ок, она не складывает, а передает сразу захардкоденное значение, соответствующее одному из ожидаемых разработчиком поведений. Оно соответствует интерфейсу, но интерфейс не передает логику работы, которая реализуется непосредственно в методе зависимости. Логика кардинально изменилась, и зависимость т.о. стала неуместной, хоть и по прежнему соответствует интерфейсу. Как это покажет замоканный тест?
Нет смысла придумывать гипотетическое решение для упрощенного гипотетического примера. Допустим, зависимость умела складывать два числа и была типизирована number, потом логика изменилась, и она стала умножать эти числа. Типизация не изменилась, тесты непосредственно зависимости исправлены, про то, что её еще где-то там зачем-то используют вообще забыли. Тем более, что на тестах эта зависимость мокается и до сих пор складывает два числа. Чем больше моков и чем больше проект, тем вероятнее похожа ситуация, когда на тестах все тип-топ, а у тестировщиков баги. Тут можно сослаться на плохую архитектуру, плохо распределенные ответственности и другими словами рекомендовать не допускать ошибок. Тем более, что в последнем случаи и тесты можно выкинуть, и типизация не нужна. Если же все-таки мы допускаем ошибки и тестирование нужно, чтобы их отловить, то каждый лишний мок должен снижать уверенность в надежности тестов.
Это если типизация возвращаемого изменится, то да, тайпскрипт не собирётся. А если логика возвращения? В моке допустим возвращается массив из двух объектов, а реально метод даёт другой, хоть и соответствующий интерфейсу. Если бы типизация позволяла исключить такие проблемы, то и тесты были бы не нужны
А нет ли каких-нибудь примеров этих сложных проектов с миллионными оборотами? Просто вообще непонятно, если есть что то прям сложное, то это же по определению исключает готовые модули? И вот здесь все говорят о плюсах по сравнению с другими, а имеют ли сравнивающие реальное представление о чем-то другом? О безопасности там, гибкости?
Я так понимаю, что под администратором имеется ввиду работник, который наполняет новости на сайте и в принципе в объявлениях о работе говорится, что он ещё предлагает предложения по развитию, нанимает сторонних программистов по согласованию с начальством. По факту не знаю, что они там ещё делают, но сомневаюсь, что данный труд требует глубокой компетенции.
Вообще, не понимаю, что можно 9ть лет изучать в какой-нибудь cms. Года через два три разраб уже наверно должен начать разрабатывать дополнения, немного набить в этом руку, а куда дальше развиваться в рамках блоговой cms?
Ну, а как быть с переписыванием черновиков, зачеркиванием, надписыванием поверх зачёркнутого и вписыванием текста на полях? Оно конечно мило, но как-то совсем не практично
Ну, вы наверно на в стародавние времена, на стародавних версиях делали, с es3. С чего бы браузерам в хп его не поддерживать? А большая тройка как тогда? Это ж считай весь инет, если вместе с джиквери.
Тут есть варианты. Когда запас истощается, и ты вот физически не можешь работать, сколько бы времени не заставлял себя пялиться в монитор, мозг тупо не соображает. Позависал полчасика в соц.сетях и фигась - мозг опять рулит и ты норм работаешь.
Дизайнер чего? Если веб, то до недавнего времени был не мыслим без фотошопа, и сейчас пикселеграфика без него не обходится, хотя есть варианты, становящиеся стандартом де факто. Дизайнеры вроде как зависимы от произовадительности машины и от софта, как вы справляетесь, имея оригинальные предпочтения в технике?
А теляфончики там какие, справа фито-дизайнерский изыск. У нас бы сказали "совок"
Антивирусы на ХП глючили году в 15-16м. Я свалил именно тогда и только потому, что пришлось работать с прогой с флеш-интерфейсом, которая подгружала комп. А потом от неё отказались, потому что она и клиентские компы подгружала в хлам, но полгода надо было побеждать это чудо за зарплату. Касперский вродь поддерживал, но у меня была установлена винда на неудачную файловую систему еще в школьничестве и работала, я не менял. Что до серфинга, то неизвестно, смогут ли барузеры с современным апи, всеми этими флексами да гридами например, работать на хп сейчас. Огнелись вот актуальный вредничает https://www.mozilla.org/en-US/firefox/95.0.2/system-requirements/
А я не люблю хромые браузеры, например.
Битрейт, это же больше про скорость инета, а не про производительность?
Я вот Масяню помню только по намедням. Толи инет был слаб, то-ли не было его ещё. Помню бесконечные форумы, долгую загрузку картинок, а вот чтобы оно подвисало или не подвисало - в памяти вообще не отложилось. Какие-то архивы с приколами смутно припоминаю,что они были,но не более. Вот здорово было бы посмотреть на документальный артефакт из античного веба, в котором вот эти вот флеши все испортили. "Здорово", потому что свидетельство для контраста о том, что все летало, у нас уже есть.
А можно как-нибудь ещё подробнее про сжирание внимания и ниши работы-творчества? У вас позиция оригинальная, так что не стесняйтесь рассказать как можно подробнее
Я не в курсе, а как у нас с кражей великов? У нас не могут сказать, что формально работать будут, но по факту забудьте?
Хотел бы вспоминить анекдот про плитку, но никогда его не знал. И что делать?
Юниор - это что-то советско-спортивное.А тут джунки - джутянки
С августа держу, можно уже отпускать?
С дамой мидлом уже как то криво вышло. Он же не милед. Куда там джунеорку обозначить?
Если класс непосредственно инжектит в себя какую-то зависимость и пользует её в своих методах, то какой тут должен быть "верхний код"? "правильная-не правильная" понятия изменяемые с течением времени и в предложенном примере одна зависимость все-таки отстала от другой и стала "неправильной".
Ок, она не складывает, а передает сразу захардкоденное значение, соответствующее одному из ожидаемых разработчиком поведений. Оно соответствует интерфейсу, но интерфейс не передает логику работы, которая реализуется непосредственно в методе зависимости. Логика кардинально изменилась, и зависимость т.о. стала неуместной, хоть и по прежнему соответствует интерфейсу. Как это покажет замоканный тест?
Нет смысла придумывать гипотетическое решение для упрощенного гипотетического примера. Допустим, зависимость умела складывать два числа и была типизирована number, потом логика изменилась, и она стала умножать эти числа. Типизация не изменилась, тесты непосредственно зависимости исправлены, про то, что её еще где-то там зачем-то используют вообще забыли. Тем более, что на тестах эта зависимость мокается и до сих пор складывает два числа. Чем больше моков и чем больше проект, тем вероятнее похожа ситуация, когда на тестах все тип-топ, а у тестировщиков баги. Тут можно сослаться на плохую архитектуру, плохо распределенные ответственности и другими словами рекомендовать не допускать ошибок. Тем более, что в последнем случаи и тесты можно выкинуть, и типизация не нужна. Если же все-таки мы допускаем ошибки и тестирование нужно, чтобы их отловить, то каждый лишний мок должен снижать уверенность в надежности тестов.
Почему просят - понятно. Вопрос, почему авторы статей не у пускают случая несколько преукрасить текст, не явно выдавая желаемое за действительное?)))
Эдак просящих будет только больше, но получат ли они желаемое? Нереализуемые желания развивают неврозы же))
От оно чего, а зачем тогда указывать цифры, которые просят, а не получают?
Это если типизация возвращаемого изменится, то да, тайпскрипт не собирётся. А если логика возвращения? В моке допустим возвращается массив из двух объектов, а реально метод даёт другой, хоть и соответствующий интерфейсу. Если бы типизация позволяла исключить такие проблемы, то и тесты были бы не нужны