Не знаю где вы такие дешевые VDS нашли виртуальный хостинг в любом случае намного дешевле
Не буду рекламу делать, но могу скинуть прайс:
скриншот
VPS/VDS - это тоже виртуальный хостинг, первая буква обязывает.
не требует никаколго дминистрирования настройки ПО и прочего в отличие от VDS.
Во-первых, многие хостеры предлагают предустановку привычной панели управления, во-вторых, минимальная настройка VPS описывается одним блоговым постом, коих уже миллион понаписано. Обслуживать VPS нужно не больше шареда.
зачем человеку который держит сайт для кафе или ИМ переплачивать если можно поставить WP на гаред хостинг
Про социалки рядом тоже в кассу заметили - они нынче достаточно могучие и имеют больше возможностей продвижения. Для типового решения не нужен WP. Для кастомного решения - лучше заплатить специалисту, чтобы не огрести проблем для бизнеса из-за дилетантских ошибок и получить качественный продукт. А специалисту это не преимущество.
WP - это как Excel на котором обширное использование макросов - это уже плохая идея.
чем дороже и сложнее стек и деплой тем лучше - больше денег.
Деплой всегда должен сводиться к кнопке с зеленой стрелочкой или запуску одного скрипта. Стеки чаще всего бесплатные, а сложность условного NodeJS не то, чтобы выше того же PHP.
Для кого это преимущество? Для микробизнесменов, которые сами могут WP развернуть? Или для отчаившихся программистов на дне рынка, которые иначе не умеют? Сейчас дешевый VPS стоит в месяц меньше чашки кофе.
Когда читающему код, встретится ошибка типа throw, ему будет сложно найти, где именно будет обрабатываться эта ошибка. Придётся проследить стек вызовов в восходящем направлении и найти все блоки catch, чтобы определить, какая инструкция будет выполняться после каждого throw.
Точно так же придется проследовать по стеку вызовов в поисках обработчика - "скачки" никуда не денутся, хотя и станут явными. Разве не странно, что сравнения эквивалентного кода в статье нет? 😉
В идеале - нужны примеры с пробросами и с обработкой части возможных типов ошибок (чтоб прям ад из алиасов!). Это бы явно показало количество хрупкого инфраструктурного кода, требующегося для поддержки этого механизма, что в случае исключений работает "само собой".
Компилятор TypeScript проверяет все эти случаи и обеспечивает правильную обработку userResult.error.code.
Насколько я понимаю, switch не требует обработки всех вариантов, а проверка контрактов - не проверяет избыточность типа резалт.
Может это будет звучать очевидно, но для многих это не так, судя по комментариям: чтобы хорошо пройти собеседование не обязательно дать правильные ответы на каждый вопрос. Задача интервьюера - нащупать слабые места и глубину знаний кандидата, а не прогнать по формальному чек-листу и подсчитать сумму баллов. То есть результат определяет достижение необходимой глубины по всем важным областям, а не количество правильных ответов.
Если вас умудрились "завалить" только на вопросах-ультрахард, где нужны энциклопедические знания или специфический опыт, то вы - большой молодец и наверняка получите респект от интервьюера, хотя и не ответили. Если же кандидат знает везде, но лишь по верхам - то дальше рискует не пройти, не смотря на количество правильных ответов.
Как это сакральное знание влияет на написание кода?
Если вы знаете устройство платформы, ее сильные и слабые стороны, это позволит делать более производительный, экономный по ресурсам код. Это позволит со знанием дела анализировать проблемы по памяти и пользоваться профайлером.
Не знать совсем глубоких нюансов или забыть детали - это нормально и едва ли это "снимет баллы". Но если кандидат позиционирует себя опытным специалистом, а при упоминании поколений объектов делает совсем круглые глаза и/или несет окровенный бред, то это, как минимум, повод насторожиться и прощупать базу. Может это единственный пробел, тогда это не проблема, но если там откроется бездна, то использование избитого вопроса окупится сполна.
Это профанация, которая конфликтует с законами, но подается под видом серьезной бумаги. Равно как документы на иностранных языках без перевода, запрет на трудоустройство к конкурентам после увольнения, какие-то конские прописанные штрафы и подобные финты, не предусмотренные ТК.
Если NDA противоречит законам юрисдикции, то оно идет лесом юридически ничтожно.
Федеральный закон от 29.07.2004 N 98-ФЗ (ред. от 08.08.2024) "О коммерческой тайне":
Статья 5. Сведения, которые не могут составлять коммерческую тайну:
о численности, о составе работников, о системе оплаты труда, об условиях труда, в том числе об охране труда, о показателях производственного травматизма и профессиональной заболеваемости, и о наличии свободных рабочих мест;
Тем не менее, заработная плата может быть персональными данные работника (программист Олег у нас в компании Y зарабатывает 300 к₽/с), поэтому про коллегу рассказывать нельзя. Но можно сказать, что программист у нас в компании Y зарабатывает 300 к₽/с.
ORM делает простым и без того простое, а сложное - еще сложнее.
Пока не запустите - не добудете запрос, можете лишь полагаться на опыт и здравый смысл, прогнозируя выхлоп, а EF умеет удивлять. Экспрешны дают некоторую статическую типизацию, но если углубиться в их генерацию - можно здорово наотстреливать ног в рантайме, да так, что ревьюер не догадается, а компилятор - не подстрахует.
С другой стороны, писать запросы руками - это не сложное занятие, с маппингом типов справится какой-нибудь Dapper. Даже если запрос билдится - это будет что-то тривиальное, сложностью управлять здесь очень просто, в отличие от абстракций экспрешнов с СУБД-специфичной трансляцией. Статической проверки типов в запросе нет, но явные имена полей и таблиц поддаются грепу.
Для таких запрсов имеется RAW режим.
Когда сырых запросов достаточно много, возникает вопрос: а стоит ли игра свеч? Стремились к простоте, а получили ласкутное одеяло технологий, альтернативных решений и срачи в ревью о границах допустимой сложности.
К тому же, EF Core лишь относительно недавно вообще научился запрашивать unmapped types, без чего в этом режиме было мало смысла.
При таком подходе запрос не засоряет Go код и удобно читается.
Но зачем? Запрос - это полноценная часть логики, в чем выигрыш вынесения в отдельный файл? Тут упомянали анализ инструментами, но ведь тот же GoLand умеет проверять SQL в литералах.
Это все, чтобы легитимизировать для себя использование margin для блоков? 😉
Проблема с отступами — в чистом БЭМе блок не должен иметь margin, поэтому приходится создавать дополнительные обертки
Сложность переиспользования для позиционирования — приходится создавать множество модификаторов (block_position-top_margin-left_slightly-to-the-right-no-not-that-right-a-bit-more... идеально!)
То есть в п.4 вы решились нарушить п.2 и поплатились 😁
Разве схлопывание марджинов - это не та сложность переиспользования, с которой предназначены бороться обертки с паддингами?
Типичная работа, допустим, на 95% состоит из простой рутины, а, условно, оставшиеся 5% - из поиска неочевидных проблем/внедрения чего-то нового, что требует некоторой эрудиции и глубины знаний. Позиция звучит так, будто вопросы, актуальные для этх 5% не относятся к "реальной вакансии". Но ведь и эту часть работы тоже необходимо выполнять.
Адаптация подвела. Оригинальная книга опирается на Java 7-, до появления Optional<T>, сейчас этот совет звучал бы иначе. А в C# совет тоже работал, но потерял актуальность с недавних пор - завезли свой эрзац-optional в виде признака нуллабельности референсных типов.
Тем не менее, NRE - это однозначное зло, допускать их появление (полагаться на них, как на ассерт, к примеру)- плохая идея.
Плюсов много, да, но не соглашусь, что решение идеально.
Объединение нескольких (списков типов/discriminated unions) ошибок в единственный тип при пробросе ошибок наверх - это боль и туча бойлерплейта маппинга типов, а рефакторинг в таких условиях - дабл-боль. А если еще и вручную проверку результата нужно делать (отстствует аналог растового ?) - трипл-боль, код раздувается огромным количеством шума чуть ли не в разы (получи результат => проверь результат и подними ошибку => распакуй результат).
Обработка исключений этих проблем лишина, т.к. появляется только там, где это имеет смысл, никаких обвязок для проталкивания ошибки наверх и "запаковки типов" не нужно => нет кода - нет и необходимости его поддерживать.
Не буду рекламу делать, но могу скинуть прайс:
скриншот
VPS/VDS - это тоже виртуальный хостинг, первая буква обязывает.
Во-первых, многие хостеры предлагают предустановку привычной панели управления, во-вторых, минимальная настройка VPS описывается одним блоговым постом, коих уже миллион понаписано. Обслуживать VPS нужно не больше шареда.
Про социалки рядом тоже в кассу заметили - они нынче достаточно могучие и имеют больше возможностей продвижения. Для типового решения не нужен WP. Для кастомного решения - лучше заплатить специалисту, чтобы не огрести проблем для бизнеса из-за дилетантских ошибок и получить качественный продукт. А специалисту это не преимущество.
WP - это как Excel на котором обширное использование макросов - это уже плохая идея.
Деплой всегда должен сводиться к кнопке с зеленой стрелочкой или запуску одного скрипта. Стеки чаще всего бесплатные, а сложность условного NodeJS не то, чтобы выше того же PHP.
Костыль, чтобы затащить PHP на лямбду? Преимущества отклеились же.
Для кого это преимущество? Для микробизнесменов, которые сами могут WP развернуть? Или для отчаившихся программистов на дне рынка, которые иначе не умеют? Сейчас дешевый VPS стоит в месяц меньше чашки кофе.
Точно так же придется проследовать по стеку вызовов в поисках обработчика - "скачки" никуда не денутся, хотя и станут явными. Разве не странно, что сравнения эквивалентного кода в статье нет? 😉
В идеале - нужны примеры с пробросами и с обработкой части возможных типов ошибок (чтоб прям ад из алиасов!). Это бы явно показало количество хрупкого инфраструктурного кода, требующегося для поддержки этого механизма, что в случае исключений работает "само собой".
Насколько я понимаю,
switchне требует обработки всех вариантов, а проверка контрактов - не проверяет избыточность типа резалт.9 из 10 стоматологов рекомендуют, ага.
Может это будет звучать очевидно, но для многих это не так, судя по комментариям: чтобы хорошо пройти собеседование не обязательно дать правильные ответы на каждый вопрос. Задача интервьюера - нащупать слабые места и глубину знаний кандидата, а не прогнать по формальному чек-листу и подсчитать сумму баллов. То есть результат определяет достижение необходимой глубины по всем важным областям, а не количество правильных ответов.
Если вас умудрились "завалить" только на вопросах-ультрахард, где нужны энциклопедические знания или специфический опыт, то вы - большой молодец и наверняка получите респект от интервьюера, хотя и не ответили. Если же кандидат знает везде, но лишь по верхам - то дальше рискует не пройти, не смотря на количество правильных ответов.
Если вы знаете устройство платформы, ее сильные и слабые стороны, это позволит делать более производительный, экономный по ресурсам код. Это позволит со знанием дела анализировать проблемы по памяти и пользоваться профайлером.
Не знать совсем глубоких нюансов или забыть детали - это нормально и едва ли это "снимет баллы". Но если кандидат позиционирует себя опытным специалистом, а при упоминании поколений объектов делает совсем круглые глаза и/или несет окровенный бред, то это, как минимум, повод насторожиться и прощупать базу. Может это единственный пробел, тогда это не проблема, но если там откроется бездна, то использование избитого вопроса окупится сполна.
Это профанация, которая конфликтует с законами, но подается под видом серьезной бумаги. Равно как документы на иностранных языках без перевода, запрет на трудоустройство к конкурентам после увольнения, какие-то конские прописанные штрафы и подобные финты, не предусмотренные ТК.
Если NDA противоречит законам юрисдикции, то оно
идет лесомюридически ничтожно.Федеральный закон от 29.07.2004 N 98-ФЗ (ред. от 08.08.2024) "О коммерческой тайне":
Тем не менее, заработная плата может быть персональными данные работника (программист Олег у нас в компании Y зарабатывает 300 к₽/с), поэтому про коллегу рассказывать нельзя. Но можно сказать, что программист у нас в компании Y зарабатывает 300 к₽/с.
В ХХ есть настройки видимости резюме с функционалом скрытия резюме для списка компаний.
Джойны в ORM - это либо те же много букв (деревья анонимных типов), либо черная магия (Automapper), либо оверфетчинг.
Если кого-то заинтересует, о каком кобанчике идет речь
ORM делает простым и без того простое, а сложное - еще сложнее.
Пока не запустите - не добудете запрос, можете лишь полагаться на опыт и здравый смысл, прогнозируя выхлоп, а EF умеет удивлять. Экспрешны дают некоторую статическую типизацию, но если углубиться в их генерацию - можно здорово наотстреливать ног в рантайме, да так, что ревьюер не догадается, а компилятор - не подстрахует.
С другой стороны, писать запросы руками - это не сложное занятие, с маппингом типов справится какой-нибудь Dapper. Даже если запрос билдится - это будет что-то тривиальное, сложностью управлять здесь очень просто, в отличие от абстракций экспрешнов с СУБД-специфичной трансляцией. Статической проверки типов в запросе нет, но явные имена полей и таблиц поддаются грепу.
Когда сырых запросов достаточно много, возникает вопрос: а стоит ли игра свеч? Стремились к простоте, а получили ласкутное одеяло технологий, альтернативных решений и срачи в ревью о границах допустимой сложности.
К тому же, EF Core лишь относительно недавно вообще научился запрашивать unmapped types, без чего в этом режиме было мало смысла.
А в чем тут языковая разница?
Но зачем? Запрос - это полноценная часть логики, в чем выигрыш вынесения в отдельный файл? Тут упомянали анализ инструментами, но ведь тот же GoLand умеет проверять SQL в литералах.
Это все, чтобы легитимизировать для себя использование
marginдля блоков? 😉То есть в п.4 вы решились нарушить п.2 и поплатились 😁
Разве схлопывание марджинов - это не та сложность переиспользования, с которой предназначены бороться обертки с паддингами?
Если не отменяет, то комментарий выше не потерял актуальность.
Ну почему же коней, вы выше сами предлагали отталкиваться от вакансии, а теперь почему-то - от кандидата.
Типичная работа, допустим, на 95% состоит из простой рутины, а, условно, оставшиеся 5% - из поиска неочевидных проблем/внедрения чего-то нового, что требует некоторой эрудиции и глубины знаний. Позиция звучит так, будто вопросы, актуальные для этх 5% не относятся к "реальной вакансии". Но ведь и эту часть работы тоже необходимо выполнять.
Адаптация подвела. Оригинальная книга опирается на Java 7-, до появления
Optional<T>, сейчас этот совет звучал бы иначе. А в C# совет тоже работал, но потерял актуальность с недавних пор - завезли свой эрзац-optional в виде признака нуллабельности референсных типов.Тем не менее, NRE - это однозначное зло, допускать их появление (полагаться на них, как на ассерт, к примеру)- плохая идея.
Плюсов много, да, но не соглашусь, что решение идеально.
Объединение нескольких (списков типов/discriminated unions) ошибок в единственный тип при пробросе ошибок наверх - это боль и туча бойлерплейта маппинга типов, а рефакторинг в таких условиях - дабл-боль. А если еще и вручную проверку результата нужно делать (отстствует аналог растового
?) - трипл-боль, код раздувается огромным количеством шума чуть ли не в разы (получи результат => проверь результат и подними ошибку => распакуй результат).Обработка исключений этих проблем лишина, т.к. появляется только там, где это имеет смысл, никаких обвязок для проталкивания ошибки наверх и "запаковки типов" не нужно => нет кода - нет и необходимости его поддерживать.