Между прочим для разработки на PHP, как актуальны знания, чем epoll отличается от select, так и что такое DDD. Рекомендую Вам, не ставить на себе крест, а почитать литературу о современной архитектуре. Она доступна всем, независимо от страны проживания.
Всё так и происходит. А когда у кандидата возникают неожиданные съезды с темы, мы ему говорим: напоминаем, что целью этого интервью является…
Такие претенденты «с особенностями» встречаются не часто. Когда я вижу, что возникают не технические трудности, я просто вежливо сворачиваю интервью, потому что не вижу смысла тратить своё время на фрагмент не из нашего пазла.
В случае же троллинга со стороны кандидата, он выступает на своём поле и мы не можем ему парировать, потому что интервьюер ограничен определёнными рамками корпоративной этики.
Бывает так, что приходит кандидат, но отказывается показать код, ссылаясь на NDA (требование примеров кода присутствует в объявлении).
Далее кандидат получает набор вопросов и относится к ним поверхностно, т.е. недостаточно для полноценной оценки знаний. Тогда кандидат получает дополнительные, уточняющие вопросы, нацеленные на раскрытие его знаний в разных сферах. Кандидат начинает воспринимать это как нападение, когда на самом деле это просто очередной шанс показать себя лучше остальных претендентов.
Далее кандидат получает тестовое задание на 2-3 часа и это бывает тоже сильно удручает специалиста.
Кандидат зачастую не понимает, что у интервьюера нет цели принизить его способности. Никто не собирается с ним сходу дружить или воевать. Для интевьюера — это просто очередной персонаж, с которым сложно находить общий язык.
У интервьюера за плечами общение с разными людьми, и у него уже сложился образ адекватного сотрудника, которые уже устроились в компанию и есть с кем сравнивать.
К сожалению, такие люди действительно попадаются и портят настроение чужим, незнакомым людям. Хороший совет, не принимать интервью близко к сердцу. Если вы (кандидат, интевьюер) уже уверены в своей правде, то зачем вам её доказывать противоположной стороне?
Пожалуйста, приведите пример. Потому что мои варианты кастинга с фильтрацией, как раз нормализуют входящие значения, чтобы избежать проблем, описываемых вами. Я считаю, что они не способствуют появлению проблемы, а наоборот.
Я не понимаю, почему эти методы должны как-то вредно взаимодействовать с вендорским кодом. Они будут использоваться только в рамках нашей кодовой базы.
В этих функциях есть второй параметр, который определяет применяемую фильтрацию, и всегда можно установить поведение по-умолчанию, как и усилить правила фильтрации, напр, вместо F_INT, использовать F_INT_POSITIVE, F_INT_POSITIVE_OR_ZERO.
Эти функции не предназначены для валидации значений, а только для каста. Какие конкретно приведения в null вам кажутся странными? Почему toInt(null), toBool(null), toFloat(null), toString(null) производит null, я объяснил, мы хотим отличать неустановленное значение от 0, false, 0.0, "". Другие моменты, я тоже попытался обосновать.
Т.е. вы считаете, что (bool)«0.0» === true — это корректно, когда (bool)«0» === false?
Причем здесь перфекционизм? Инструмент должен работать однозначно и быть интуитивно понятным. Могу парировать, что у вас пхп головного мозга, раз вы бескомпромистно полагаетесь на правила кастинга, изобретенные специально для пхп и не повторяющиеся в других ЯП.
И я не понял, какие проблемы меня ждут после перехода на пхп8? Пожалуйста, разъясните.
Продолжая тему wiki.php.net/rfc/string_to_number_comparison и неудачных примеров приведения типов в пхп, я выражаю свое согласие с вышеизложенными предложениями, они соответствуют моему виденью и нашли применения в моих ф-циях toInt(), toFloat().
Я хотел бы обсудить аналогичную проблему каста в Boolean и String. Я столкнулся со следующими примерами, которые считаю неудачными и планирую переопределить в своих функциях кастования типа. В них я разграничиваю входные данные на ожидаемые и не ожидаемые для каждого из приведений типа.
1) Случаи приведения типа в Boolean и моей ф-ции toBool().
1.1) Стандартный каст (bool)5, (bool)-1 производят true. Я не считаю, что это правильно. Да, мы можем ожидать «1», «0», «1.0», «0.0», " 1 ", " 0 ", как репрезентацию true/false значений. Но если приходит 5 или -1 — это скорее говорит об ошибке переданных данных, чем об удачной возможности воспользоваться «магическим» преобразованием из коробки пхп.
В моем случае toBool(5), toBool(-1) вернет Null значение, которое я возвращаю, в случае неудачной конвертации типа.
1.2) (bool)«1.0», (bool)«1», (bool), " 1.0 ", производят true, как и ожидается.
(bool)«0», производит false, как и ожидается.
Но «0.0», " 0 ", так же производят true, что мне кажется неверным, моя toBool(«0.0») вернет false.
1.3) (bool)«string» производит true, когда «string» не выглядит, как ожидаемое значение для булевого типа. В моем случае toBool(«string») возвращает null.
1.4) (bool)"" производит false, что тоже по-моему мнению не верно.
Похожий кейс обсуждается в статье для чисел, когда идет речь о сравнении (bool)(0 == ""), которое производит true, а предлагают сделать false.
Я считаю, что toBool("") должно возвращать null, но здесь у меня сомнения.
1.5) (bool)null производит false, когда я считаю, что должно производиться null. Мы ведь часто хотим иметь возможность сбрасывать булево значение в состоянии объекта, и присваивание null, как раз сбрасывает его. После, мы ориентируясь на факт, что значение сброшено (а не false), можем например загрузить значение по-умолчанию.
1.6) (bool)[1], (bool)[0] — производит true, а (bool)[] — производит false.
Я считаю, что массив — это не ожидаемое значение и не может быть преобразовано, значит надо вернуть null.
2) Случаи приведения типа в String и моя ф-ция toString().
В случае приведения типа в String, я вижу следующие сомнительные стандартные касты из коробки пхп:
2.1) Если (string)true производит «1», тогда почему (string)false производит "", а не «0»?
Я считаю, что true/false — булево значение не является ожидаемым значением для каста в стринг и в обоих случаях toString() должен вернуть null. Здесь меня терзают сомнения.
2.2) (string)[] — производит E_NOTICE ошибку: «Array to string conversion», в моем случае toString([]) вернет null.
3.1) Чтобы быть полным, хочу сказать, что я так же не считаю булевы значения, как ожидаемые для каста в числа, и toInt(true), toFloat(false) в моей парадигме произведут null
3.2) Аналогично с массивом, toInt([1]), toFloat([]) производят null.
Очень жду комментариев и мнений. Что я не предусмотрел? Наверняка, эти вопросы уже покрыты в какой-то библиотеке, куда мне следовало бы заглянуть, прежде чем описывать эти правила.
Я специально не смотрел, разве нет бесплатных аналогов такой програмки? которой всего то и надо делать снимок экрана раз в 10 минут и протоколировать кол-во нажатий клавиши и мышки. Попробуйте на себе такой процесс, удивительно избавляет от прокрастинации
У меня была такая проблема пока я не устроился работать по часовой оплате. Сколько отработаешь часов, столько получаешь денег. Программа на одеске протоколирует твоё время проведенное в работе и это подстёгивает не откладывать работу на ночь. Я так работаю полтора года, нет психологического давления, когда ты что-то откладываешь. А работодатель видит процесс твоей работы по снимкам экрана и результатам труда.
Вот вы пишете, что шторм выдаёт умные подсказки. Как я могу судить, он с ними перебарщивает и выдаёт очень много совершенно лишних и необоснованных «подсказок», видимо из-за того, что не может определить некоторые связи правильно.
Совершенно верно, мы сейчас не сравниваем IDE с легковестным редактором с подсветкой. Плюс IDE в том, что мы можем смотреть на большой проект свысока (навигация и поиск) и то что она упрощает задачи рефакторинга. Я даже не хочу услышать от вас какой-либо анализ отличий между популярными IDE. Мне просто интересны ваши случаи использования, что-нибудь такое, что я мог бы перенести в свою практику. Пока всё что вы описали, я и так использую, как вы поняли это всё работает в старом эклипсе 7, но это сейчас не важно.
Я бы не стал слушать советов человека, который первым делом говорит об IDE. Почему шторм, а не эклипс, например? У меня вот шторм тормозит на стареньком пне и я использую eclipse 7. Из всего функционала мне необходим поиск — замена с регулярными выражениями, удобная навигация, хоткеи и шаблоны команд. Это есть в любой IDE. Позвольте узнать, чего такого полезного есть в PhpStorm, что могло бы повысить мою производительность труда или облегчить процесс разработки? Мне действительно интересно, т.к. я сейчас перешел на PhpStorm, но не вижу никаких плюсов.
Я был бы только рад такой возможности освоить новые знания на реальном заказе. Другое дело, что заказчик должен понимать, что исполнитель может не знать новую платформу так хорошо, как свою родную. Мнение, что PHP плохой язык — это всё предрассудки. На нём можно писать качественный код, точно так же как и на других языках. У него много плюсов и ваш заказчик это прекрасно понимает.
Я прошу заказчика описать не только проект и поставленные задачи, но и команду с кем мне придется работать и как организован процесс. Так же в начале сотрудничества полезно выяснить перспективы более долгой работы и роста зарплаты. Эти вещи очень помогают для оценки адекватности заказчика.
Видео дайджесты в первой половине года. Ничего более радостного пхп не дарило.
Такие претенденты «с особенностями» встречаются не часто. Когда я вижу, что возникают не технические трудности, я просто вежливо сворачиваю интервью, потому что не вижу смысла тратить своё время на фрагмент не из нашего пазла.
В случае же троллинга со стороны кандидата, он выступает на своём поле и мы не можем ему парировать, потому что интервьюер ограничен определёнными рамками корпоративной этики.
Далее кандидат получает набор вопросов и относится к ним поверхностно, т.е. недостаточно для полноценной оценки знаний. Тогда кандидат получает дополнительные, уточняющие вопросы, нацеленные на раскрытие его знаний в разных сферах. Кандидат начинает воспринимать это как нападение, когда на самом деле это просто очередной шанс показать себя лучше остальных претендентов.
Далее кандидат получает тестовое задание на 2-3 часа и это бывает тоже сильно удручает специалиста.
Кандидат зачастую не понимает, что у интервьюера нет цели принизить его способности. Никто не собирается с ним сходу дружить или воевать. Для интевьюера — это просто очередной персонаж, с которым сложно находить общий язык.
У интервьюера за плечами общение с разными людьми, и у него уже сложился образ адекватного сотрудника, которые уже устроились в компанию и есть с кем сравнивать.
К сожалению, такие люди действительно попадаются и портят настроение чужим, незнакомым людям. Хороший совет, не принимать интервью близко к сердцу. Если вы (кандидат, интевьюер) уже уверены в своей правде, то зачем вам её доказывать противоположной стороне?
Я не понимаю, почему эти методы должны как-то вредно взаимодействовать с вендорским кодом. Они будут использоваться только в рамках нашей кодовой базы.
Эти функции не предназначены для валидации значений, а только для каста. Какие конкретно приведения в null вам кажутся странными? Почему toInt(null), toBool(null), toFloat(null), toString(null) производит null, я объяснил, мы хотим отличать неустановленное значение от 0, false, 0.0, "". Другие моменты, я тоже попытался обосновать.
Причем здесь перфекционизм? Инструмент должен работать однозначно и быть интуитивно понятным. Могу парировать, что у вас пхп головного мозга, раз вы бескомпромистно полагаетесь на правила кастинга, изобретенные специально для пхп и не повторяющиеся в других ЯП.
И я не понял, какие проблемы меня ждут после перехода на пхп8? Пожалуйста, разъясните.
Я хотел бы обсудить аналогичную проблему каста в Boolean и String. Я столкнулся со следующими примерами, которые считаю неудачными и планирую переопределить в своих функциях кастования типа. В них я разграничиваю входные данные на ожидаемые и не ожидаемые для каждого из приведений типа.
1) Случаи приведения типа в Boolean и моей ф-ции toBool().
1.1) Стандартный каст (bool)5, (bool)-1 производят true. Я не считаю, что это правильно. Да, мы можем ожидать «1», «0», «1.0», «0.0», " 1 ", " 0 ", как репрезентацию true/false значений. Но если приходит 5 или -1 — это скорее говорит об ошибке переданных данных, чем об удачной возможности воспользоваться «магическим» преобразованием из коробки пхп.
В моем случае toBool(5), toBool(-1) вернет Null значение, которое я возвращаю, в случае неудачной конвертации типа.
1.2) (bool)«1.0», (bool)«1», (bool), " 1.0 ", производят true, как и ожидается.
(bool)«0», производит false, как и ожидается.
Но «0.0», " 0 ", так же производят true, что мне кажется неверным, моя toBool(«0.0») вернет false.
1.3) (bool)«string» производит true, когда «string» не выглядит, как ожидаемое значение для булевого типа. В моем случае toBool(«string») возвращает null.
1.4) (bool)"" производит false, что тоже по-моему мнению не верно.
Похожий кейс обсуждается в статье для чисел, когда идет речь о сравнении (bool)(0 == ""), которое производит true, а предлагают сделать false.
Я считаю, что toBool("") должно возвращать null, но здесь у меня сомнения.
1.5) (bool)null производит false, когда я считаю, что должно производиться null. Мы ведь часто хотим иметь возможность сбрасывать булево значение в состоянии объекта, и присваивание null, как раз сбрасывает его. После, мы ориентируясь на факт, что значение сброшено (а не false), можем например загрузить значение по-умолчанию.
1.6) (bool)[1], (bool)[0] — производит true, а (bool)[] — производит false.
Я считаю, что массив — это не ожидаемое значение и не может быть преобразовано, значит надо вернуть null.
2) Случаи приведения типа в String и моя ф-ция toString().
В случае приведения типа в String, я вижу следующие сомнительные стандартные касты из коробки пхп:
2.1) Если (string)true производит «1», тогда почему (string)false производит "", а не «0»?
Я считаю, что true/false — булево значение не является ожидаемым значением для каста в стринг и в обоих случаях toString() должен вернуть null. Здесь меня терзают сомнения.
2.2) (string)[] — производит E_NOTICE ошибку: «Array to string conversion», в моем случае toString([]) вернет null.
3.1) Чтобы быть полным, хочу сказать, что я так же не считаю булевы значения, как ожидаемые для каста в числа, и toInt(true), toFloat(false) в моей парадигме произведут null
3.2) Аналогично с массивом, toInt([1]), toFloat([]) производят null.
Очень жду комментариев и мнений. Что я не предусмотрел? Наверняка, эти вопросы уже покрыты в какой-то библиотеке, куда мне следовало бы заглянуть, прежде чем описывать эти правила.
Для уточнения: паршу я дамп схемы без данных