Наш собственный тест кейс был указан как "отягощающее" состояние для тестов, у него широкий функционал и он продолжает пополняться. Поэтому, когда тестирование было только в начале разработки, применение тестовой среды для каждого теста не было проблемой. Со временем это стало занимать все больше и больше времени. Наш кастомный тест кейс как раз наследуется от TestCase, упомянутый вами.
Насчет разницы между setUpTestData() и def setUpClass() — в вашем определении не вижу противоречия с нашим. Да, def setUpClass() вызывается внутри setUpTestData(). Но так же он конфликтует с TransactionalTestCase, которые мы используем в тестировании. setUpTestData() такого конфликта не вызывает, поэтому именно его и выбрали
Есть миллион причин, по которым агентство и клиент могут не подойти друг другу. И чем раньше придет понимание этого, тем лучше для обеих сторон. Поэтому агентства подходят к выбору клиентов также тщательно, как и к поиску разработчиков. Хотя вы правы — иногда именно собеседование оказывается той точкой, когда становится понятно: "что-то пошло не так". Но это все же скорее исключение, чем правило
За всю отрасль отвечать не могу, только за себя. Мы не предлагаем разработчиков на грейд выше, чем они есть. Ситуации, когда разработчик шел на собеседование грейда мидл, а по результатам общения получал мидл+, в нашей практике случались. Продавать джуна за сеньора, писать ему фейковые CV — себе дороже. Мы предпочитаем другой путь — тщательно отбирать кандидатов, которые соответствуют заявленному грейду. Так спишь спокойнее)
Вы подняли сразу несколько важных тем. Да, конечно, собеседование ведут живые люди и от психологии уйти невозможно. Разные темпераменты, манера речи или даже банальное настроение могут повлиять на результат. Но практика и здравый смысл подсказывают, что обычно обе стороны стремятся достигнуть цель, а не самоутвердиться)
Очень интересный тезис о том, что собеседование можно случайно пройти и неслучайно завалить. Бывает так, что интервьюер задает несколько вопросов, ответы кандидата его устраивают и на этом все заканчивается — собеседование пройдено. Но возможны два исключения: ответы оказываются ниже ожидаемого уровня или ответы оказываются выше ожидаемого, то есть ответ показывает более глубокое знание.
В первом случае — очевидно, что спрашивающий пойдет копать вглубь, чтобы убедиться в компетенциях кандидата. Дальше или ОК, или следует отказ. А вот второй вариант — можно легко спутать с "специально захотели завалить". Представьте — вы интервьюер, собеседуете мидла+, а ответ получаете на уровне сеньора. В этой ситуации очень велик соблазн "прокачать ситуацию" — вдруг этого кандидата можно взять на более высокий грейд? И следуют вопросы для проверки. Хорошо, если изначальный посыл оказался верен, и перед вами действительно готовый синьор. А если нет? Тогда, увы, все заканчивается тем, что вскрываются пустоты в знаниях, до которых стандартными вопросами "по грейду" вряд ли удалось бы добраться.
Так что вы и правы, и не правы. Собеседование может завалиться, но, скорее всего, дело не в изначальном желании одной из сторон.
Про сохранение абстракций — хорошая формулировка, согласен (если добавить к ней «в том числе и...»). Но общий посыл не о том, что VDOM позволяет оптимизировать быстродействие, и не про сам VDOM как таковой. А про то, как вообще с изменением подходов и задач развивалось взаимодействие с DOM. Как решения, дававшие плюсы при одном подходе, оказывались минусами при другом, и это приводило к следующей итерации. Как и в любой статье — что-то упрощено, да. Это неизбежно, ведь и весь путь изменений в работе с DOM не был «предначертан заранее», это результат многих итераций, чтобы получить искомое. Текущее состояние тоже не финал, что-то да придет на смену.
Сравнение на примере точечного изменения тоже не совсем корректно, да и сейчас, как совершенно верно замечено, подход меняется.
А я могу поставить плюс и поставлю?, только немного переформулирую — не только для оптимизации, но и для сохранения привычных абстракций (как сказали выше в комментах). Одно другому не противоречит.
Суть фабрики — предоставление интерфейса для создания экземпляров некоего класса с возможностью в момент создания определить, экземпляр какого конкретно класса создавать.
Суть умения рассказать что-то — декомпозировать сложное до простого, упростить до состояния, понятного без дополнительного контекста.
Суть статьи — показать логику реализации, откуда растут ноги этой задачи в игровой, простой форме.
Суть процесса изучения — понять принцип и углубиться в вопрос самостоятельно.
Суть комментариев — найти недосказанное автором)) При желании — можно найти и сервис локатор (только не в свич-кейсе, а в мапе), но в рамках темы статьи — это фигура умолчания.
Никто не говорит, что в работе не надо использовать фреймворк. И вы, кстати, лишь подтверждаете основную мысль статьи — вы В САМОМ НАЧАЛЕ освоили JS, потому что он вам понадобился, а потом спокойно пошли в частности — библиотеки и фреймворки. Суть в том, что 15 лет назад именно так все и происходило, и свою базу вы считаете само собой разумеющейся. Сегодня это, мягко говоря, не так.
Увы, но процесс «изучить реакт» (или другой фремворк) без попытки понять, что у него внутри, приводит к диалогу из «Дня Радио»: «А давайте спустим им микрофоны в лифт на веревочках — у каждого микрофона сзади есть такая черненькая веревочка».
Можно выучить, когда использовать хуки. Но невозможно понять, что и как они делают, без погружения в основы.
Любые аналогии ложны, вы правы. Но при этом зачем-то передергиваете, пытаясь расширить аналогию до несводимых типов транспортных средств, рассуждая о грузчиках, и делаете вывод про отсутствие аргументов. Могу лишь вернуть этот вывод в ответ — аргументы в критике не обнаружены.
Название статьи, конечно, провокационное)) тем более что, продолжая мысль, можно написать следующую статью «Перестаньте учить JS, учите программирование» (надо будет запомнить). Но мысль не о том, что учить фреймворки НЕ НАДО. А о том, что изучить их без знания базы — нереально. И да, я принципиально разделяю «изучить» и «зазубрить, как сделать что-то». Первое подразумевает понимание, второе, по сути, копипаста с разработчиком в роли исполнительного механизма.
П.С. Вопросы по js на собеседованиях — это отдельная тема, грустная и печальная :-)
Возможно, потому что основная масса новичков сначала расшибает себе лоб об фронтенд, а на бекэнд приходит уже умудренными жизненным опытом?)) И это не учитывая того, что в статье речь и про фронт, и про бэк)
Скорее, требовать принципиальное знание устройства и правил (умения поменять колесо, понимания, что надо доливать бензин и проверять масло, знания что на красный свет ехать нельзя — в аналогиях автомобилей) — мало ли какая ситуация может случиться :-)
Кого нанимать — ваше право) как и ваш опыт сравнения. Но спасибо за яркое подтверждение основной мысли статьи — разработчик, изучавший ангулар, сходу не зайдет в реакт, и наоборот. Разработчик, изучавший JS и программирование — спокойно зайдет и в реакт, и в ангулар, и во вью.
Любой разработчик, работающий во фреймворке, пишет JS код и только его. Он работает в JS по правилам, которые ему на том же JS (с опциональной надстройкой в виде TS) задали другие программисты, за него реализовавшие часть логики, спрятав ее под капот фреймворка. И либо он это осознает и понимает не только ту часть, что снаружи, но и ту что внутри — либо нет.
Обычно != правильно. Фреймворки привлекают быстротой — установил, посмотрел получасовое видео и у тебя есть плюс-минус работающий результат, который можно потрогать. Конечно, начинать с азов не так интересно, просто и увлекательно. Но легкий старт — это самообман. Не нравится аналогия с водителями — считайте фреймворк надувной штангой)) Внешне круто, но станет ли тот, кто ее тягает, сильнее?
Спасибо за комментарий!
Наш собственный тест кейс был указан как "отягощающее" состояние для тестов, у него широкий функционал и он продолжает пополняться. Поэтому, когда тестирование было только в начале разработки, применение тестовой среды для каждого теста не было проблемой. Со временем это стало занимать все больше и больше времени. Наш кастомный тест кейс как раз наследуется от TestCase, упомянутый вами.
Насчет разницы между setUpTestData() и def setUpClass() — в вашем определении не вижу противоречия с нашим. Да, def setUpClass() вызывается внутри setUpTestData(). Но так же он конфликтует с TransactionalTestCase, которые мы используем в тестировании. setUpTestData() такого конфликта не вызывает, поэтому именно его и выбрали
К сожалению резюме по ссылке скрыто
Эфир планируем только в твиттере. Но скорее всего зальем запись на нашу страницу Вконтакте
Есть миллион причин, по которым агентство и клиент могут не подойти друг другу. И чем раньше придет понимание этого, тем лучше для обеих сторон. Поэтому агентства подходят к выбору клиентов также тщательно, как и к поиску разработчиков. Хотя вы правы — иногда именно собеседование оказывается той точкой, когда становится понятно: "что-то пошло не так". Но это все же скорее исключение, чем правило
За всю отрасль отвечать не могу, только за себя. Мы не предлагаем разработчиков на грейд выше, чем они есть. Ситуации, когда разработчик шел на собеседование грейда мидл, а по результатам общения получал мидл+, в нашей практике случались. Продавать джуна за сеньора, писать ему фейковые CV — себе дороже. Мы предпочитаем другой путь — тщательно отбирать кандидатов, которые соответствуют заявленному грейду. Так спишь спокойнее)
Вы подняли сразу несколько важных тем. Да, конечно, собеседование ведут живые люди и от психологии уйти невозможно. Разные темпераменты, манера речи или даже банальное настроение могут повлиять на результат. Но практика и здравый смысл подсказывают, что обычно обе стороны стремятся достигнуть цель, а не самоутвердиться)
Очень интересный тезис о том, что собеседование можно случайно пройти и неслучайно завалить. Бывает так, что интервьюер задает несколько вопросов, ответы кандидата его устраивают и на этом все заканчивается — собеседование пройдено. Но возможны два исключения: ответы оказываются ниже ожидаемого уровня или ответы оказываются выше ожидаемого, то есть ответ показывает более глубокое знание.
В первом случае — очевидно, что спрашивающий пойдет копать вглубь, чтобы убедиться в компетенциях кандидата. Дальше или ОК, или следует отказ. А вот второй вариант — можно легко спутать с "специально захотели завалить". Представьте — вы интервьюер, собеседуете мидла+, а ответ получаете на уровне сеньора. В этой ситуации очень велик соблазн "прокачать ситуацию" — вдруг этого кандидата можно взять на более высокий грейд? И следуют вопросы для проверки. Хорошо, если изначальный посыл оказался верен, и перед вами действительно готовый синьор. А если нет? Тогда, увы, все заканчивается тем, что вскрываются пустоты в знаниях, до которых стандартными вопросами "по грейду" вряд ли удалось бы добраться.
Так что вы и правы, и не правы. Собеседование может завалиться, но, скорее всего, дело не в изначальном желании одной из сторон.
Поздравляем, вы приняты на работу, занесите в отдел кадров ведомость "Проклятия коллег 2010-2020"))
Про сохранение абстракций — хорошая формулировка, согласен (если добавить к ней «в том числе и...»). Но общий посыл не о том, что VDOM позволяет оптимизировать быстродействие, и не про сам VDOM как таковой. А про то, как вообще с изменением подходов и задач развивалось взаимодействие с DOM. Как решения, дававшие плюсы при одном подходе, оказывались минусами при другом, и это приводило к следующей итерации. Как и в любой статье — что-то упрощено, да. Это неизбежно, ведь и весь путь изменений в работе с DOM не был «предначертан заранее», это результат многих итераций, чтобы получить искомое. Текущее состояние тоже не финал, что-то да придет на смену.
Сравнение на примере точечного изменения тоже не совсем корректно, да и сейчас, как совершенно верно замечено, подход меняется.
А я могу поставить плюс и поставлю?, только немного переформулирую — не только для оптимизации, но и для сохранения привычных абстракций (как сказали выше в комментах). Одно другому не противоречит.
Суть фабрики — предоставление интерфейса для создания экземпляров некоего класса с возможностью в момент создания определить, экземпляр какого конкретно класса создавать.
Суть умения рассказать что-то — декомпозировать сложное до простого, упростить до состояния, понятного без дополнительного контекста.
Суть статьи — показать логику реализации, откуда растут ноги этой задачи в игровой, простой форме.
Суть процесса изучения — понять принцип и углубиться в вопрос самостоятельно.
Суть комментариев — найти недосказанное автором)) При желании — можно найти и сервис локатор (только не в свич-кейсе, а в мапе), но в рамках темы статьи — это фигура умолчания.
Никто не говорит, что в работе не надо использовать фреймворк. И вы, кстати, лишь подтверждаете основную мысль статьи — вы В САМОМ НАЧАЛЕ освоили JS, потому что он вам понадобился, а потом спокойно пошли в частности — библиотеки и фреймворки. Суть в том, что 15 лет назад именно так все и происходило, и свою базу вы считаете само собой разумеющейся. Сегодня это, мягко говоря, не так.
Увы, но процесс «изучить реакт» (или другой фремворк) без попытки понять, что у него внутри, приводит к диалогу из «Дня Радио»: «А давайте спустим им микрофоны в лифт на веревочках — у каждого микрофона сзади есть такая черненькая веревочка».
Можно выучить, когда использовать хуки. Но невозможно понять, что и как они делают, без погружения в основы.
Любые аналогии ложны, вы правы. Но при этом зачем-то передергиваете, пытаясь расширить аналогию до несводимых типов транспортных средств, рассуждая о грузчиках, и делаете вывод про отсутствие аргументов. Могу лишь вернуть этот вывод в ответ — аргументы в критике не обнаружены.
Название статьи, конечно, провокационное)) тем более что, продолжая мысль, можно написать следующую статью «Перестаньте учить JS, учите программирование» (надо будет запомнить). Но мысль не о том, что учить фреймворки НЕ НАДО. А о том, что изучить их без знания базы — нереально. И да, я принципиально разделяю «изучить» и «зазубрить, как сделать что-то». Первое подразумевает понимание, второе, по сути, копипаста с разработчиком в роли исполнительного механизма.
П.С. Вопросы по js на собеседованиях — это отдельная тема, грустная и печальная :-)
По сути — ответил выше. TS это расширение, а не замещение.
П.С. Надеюсь, он никогда не выйдет из моды, уж больно хорош)))
Возможно, потому что основная масса новичков сначала расшибает себе лоб об фронтенд, а на бекэнд приходит уже умудренными жизненным опытом?)) И это не учитывая того, что в статье речь и про фронт, и про бэк)
Скорее, требовать принципиальное знание устройства и правил (умения поменять колесо, понимания, что надо доливать бензин и проверять масло, знания что на красный свет ехать нельзя — в аналогиях автомобилей) — мало ли какая ситуация может случиться :-)
Кого нанимать — ваше право) как и ваш опыт сравнения. Но спасибо за яркое подтверждение основной мысли статьи — разработчик, изучавший ангулар, сходу не зайдет в реакт, и наоборот. Разработчик, изучавший JS и программирование — спокойно зайдет и в реакт, и в ангулар, и во вью.
Любой разработчик, работающий во фреймворке, пишет JS код и только его. Он работает в JS по правилам, которые ему на том же JS (с опциональной надстройкой в виде TS) задали другие программисты, за него реализовавшие часть логики, спрятав ее под капот фреймворка. И либо он это осознает и понимает не только ту часть, что снаружи, но и ту что внутри — либо нет.
Обычно != правильно. Фреймворки привлекают быстротой — установил, посмотрел получасовое видео и у тебя есть плюс-минус работающий результат, который можно потрогать. Конечно, начинать с азов не так интересно, просто и увлекательно. Но легкий старт — это самообман. Не нравится аналогия с водителями — считайте фреймворк надувной штангой)) Внешне круто, но станет ли тот, кто ее тягает, сильнее?