Конкретно в этом примере const не применим. var и let действительно будут вести себя по-разному.
Тем не менее, пример проверят понимание базовых конструкций языка. если сеньор не может объяснить, что происходит в этом фрагменте кода — большой вопрос, что за сеньор перед нами.
От заученных вопросов отлично помогает просьба объяснить свой ответ. И тогда будет понятно, не обратил ли внимания человек на let/var, перепутал/подзабыл из-за неактуальности var или вообще не имеет представления, что в этом фрагменте происходит. Последнее встречается достаточно часто.
Частота кейса лично у меня ничего не говорит о давности JS прямо сейчас: код с var не стал чем-то экзотическим, а замыкания используются повсеместно. И аналогичный код с let я считаю тем же кейсом — это все еще замыкание (другая область видимости — незначительная деталь).
Я не переводчик, но позволю себе ответить. Негативное пространство — термин из изобразительного искусства. Упрощенно — пустое пространство или пространство между объектами.
Люди, у кого написано «не ищу», нередко готовы обсуждать вакансии.
А те, у кого написано «ищу», ничего не ищут, уже или вообще. Или резюме уже давно во внутренней базе рекрутеров, где по понятным причинам актуального статуса нет.
Кажется, что в самом факте предложения обсудить вакансию нет ничего невежливого.
вы в своем варианте поиска не оставили себе возможности как-либо сделать эту проверку. потому что NULL не может быть ключем хеш-таблицы. При наличии, например, одновременно пустой строки и NULL в одном массиве, вы одно из этих значений потеряете и уже не сможете найти.
Вы сравнивали in_array не с array_key_exists, а с isset. Это несколько разные вещи хотя бы потому, что isset не является функцией и дает другой результат. Попробуйте добавить NULL в изначальный массив и посмотрите, что вам вернет isset при попытке узнать, есть ли в массиве этот NULL.
Про необходимость включения array_combine (или array_flip) в тело цикла для корректного сравнения вам уже выше написали. И если делать честное сравнение с array_flip+isset/array_key_exists, то получим результат в разы хуже, чем если бы использовали in_array.
А зачем измерять результат работы единственным числом? KPI может складываться и из множества отдельных показателей, которые могут показывать как общий результат, так и некоторые промежуточные итоги.
Тот же пример про число звонков из статьи. Я еще нигде не видел, чтобы эффективность менеджера измеряли исключительно количеством звонков, хотя оно и может входить в KPI как один из показателей. KPI в этом случае дополняют, например, объемом продаж, числом новых клиентов, средней стоимостью заказа, числом привлеченных ключевых клиентов, объемом дебеторской задолженности и прочими куда более важными вещами. И звонок еще может не любой в зачет пойти.
Так может быть, надо было искать не решение конкретной задачи со всеми ее особенностями, а решение класса подобных задач, да изучать основы?
Банальный запрос «подсчет числа строк mysql» в Гугле первой же ссылкой дает описание COUNT(). Так что непонятно, как вы искали.
Что касается улучшений и оптимизации, то улучшать здесь ничего не надо. Надо переписать все полностью.
По теме написано ровно две строчки ($SxGeo = new SxGeo и далее), да и те находятся по первой же ссылке в Гугле.
MAX(`id`) и общее количество посещений — совершенно разные понятия, никак не связанные.
Делать полную выборку (SELECT *) только ради подсчета строк — не самое умное решение, мягко говоря.
Про подключение к mysql из php все написано в документации по самому php, и даже больше, чем здесь.
Заплатив за код или дизайн сотрудникам или фрилансерам, вы НЕ становитесь его владельцем
Это не совсем так. Вернее, совсем не так, если говорить о сотрудниках. Статья 1295, п. 2: исключительное право на служебное произведение принадлежит работодателю, если трудовым или гражданско-правовым договором между работодателем и автором не предусмотрено иное.
Вы в точности описали инструкцию, как стать заказчиком из ада и с большой вероятностью получить минимально возможную отдачу от проекта в последствии.
Большинство заказчиков — специалисты в своем бизнесе, а не в пользовательских интерфейсах и информационной архитектуре. И даже если ваш дизайнер не имеет серьезного опыта проектирования и не обладает большими познаниями в области юзабилити, эти понятия ему ближе, чем директору, скажем, строительной компании. Заставьте этого директора располагать блоки, указывать на необходимое оформление элементов — вы в 99% случаев получаете совершенно не приспособленный к использованию людьми проект. И даже понимание сегментов аудитории, с которой необходимо работать, этому заказчику не сильно поможет.
Пример из жизни: клиент долго доказывал нам, что наиболее важным свойством товаров с точки зрения навигации по каталогу и выбора товара является бренд. Поскольку клиент пытался поступать именно как вы советуете, пришлось тут же обратиться к продавцу в торговом зале с вопросом «Что справшивает покупатель первым делом, когда подбирает нужный товар?». Ответ полностью опроверг утверждение клиента — «А есть у вас [некий_товар] на десятку?» либо «Нужен [некий_товар] размером XX мм»
Другой пример: клиент предоставил все идеальные по его мнению интерфейсы, описание работы каждого элемента системы. Любые попытки что-либо изменить в лучшую сторону отклонялись, поскольку разработчики не специалисты в его сфере и процессах его компании — воспринимаются именно как операторы ПК.
Как вы думаете, кто первым потом плевался и кричал, что работать с этим творением невозможно?
И если бы таких случаев было только два, но они возникают постоянно.
Что касается решения этих проблем вставкой менеджера проекта между дизайнером и клиентом. Менеджер проекта — он все же менеджер. В его компетенции входит управление проектом, а не разработка каждого отдельного компонента этого проекта. Это все же не специалист по интерфейсам и юзабилити, маркетолог и редактор в одном лице.
Заказчик же должен просто объяснить, какие задачи необходимо решить, каких целей необходимо достигнуть (не «хочу меню слева», а «надо увеличить продажи диванов на 20% минимум к сентябрю»). А уже дизайнеры и специалисты в смежных областях пусть думают, как эти задачи решить наиболее эффективно.
Советы справедливы и очевидны для разработки большинства систем (плюс-минус мультиязычность).
Но вот в стартапах, как мне кажется, перебор. Если вы работаете над стартапом, вам нужно как можно быстрее запуститься с минимумом вложений и проверить все свои теории. А иначе есть риск потратить не один месяц на мультиязычность, шардинг БД, все мыслимые и немыслимые API, съесть весь собственный бюджет и все инвестиции (если таковые имелись), а потом окажется, что ваш проект никому не нужен.
Так ведь никто не заставляет все и всегда описывать в каких-то единицах.
К недавней записи можно написать, например, «about 1 hour ago». А в вашем примере вместо 16-часов указать «last morning», или же вовсе для сильно старых записей указывать точное время
> Для книг, которые Вы планируете продавать, необходимо наличие ISBN
Это закреплено в соответствующих нормативных актах и в законодательстве РФ.
И мало того, что вы должы получить ISBN-коды (разные для разных носителей), вы еще и обязаны определенное количество копий предоставить в день сдачи тиража в книжную палату, которая распределит эти копии по библиотекам и различным учреждениям. Для простой бумажной книги — 11 копий. Для электронной версии — 3 копии на соответствующих носителях.
Конкретно в этом примере const не применим. var и let действительно будут вести себя по-разному.
Тем не менее, пример проверят понимание базовых конструкций языка. если сеньор не может объяснить, что происходит в этом фрагменте кода — большой вопрос, что за сеньор перед нами.
От заученных вопросов отлично помогает просьба объяснить свой ответ. И тогда будет понятно, не обратил ли внимания человек на let/var, перепутал/подзабыл из-за неактуальности var или вообще не имеет представления, что в этом фрагменте происходит. Последнее встречается достаточно часто.
Частота кейса лично у меня ничего не говорит о давности JS прямо сейчас: код с var не стал чем-то экзотическим, а замыкания используются повсеместно. И аналогичный код с let я считаю тем же кейсом — это все еще замыкание (другая область видимости — незначительная деталь).
Неоднократно встречал такой кейс в реальной работе.
Это же вопрос просто на понимание замыканий. Их использование - не какой-то исключительный случай.
Я не переводчик, но позволю себе ответить. Негативное пространство — термин из изобразительного искусства. Упрощенно — пустое пространство или пространство между объектами.
А те, у кого написано «ищу», ничего не ищут, уже или вообще. Или резюме уже давно во внутренней базе рекрутеров, где по понятным причинам актуального статуса нет.
Кажется, что в самом факте предложения обсудить вакансию нет ничего невежливого.
Про необходимость включения array_combine (или array_flip) в тело цикла для корректного сравнения вам уже выше написали. И если делать честное сравнение с array_flip+isset/array_key_exists, то получим результат в разы хуже, чем если бы использовали in_array.
Тот же пример про число звонков из статьи. Я еще нигде не видел, чтобы эффективность менеджера измеряли исключительно количеством звонков, хотя оно и может входить в KPI как один из показателей. KPI в этом случае дополняют, например, объемом продаж, числом новых клиентов, средней стоимостью заказа, числом привлеченных ключевых клиентов, объемом дебеторской задолженности и прочими куда более важными вещами. И звонок еще может не любой в зачет пойти.
Банальный запрос «подсчет числа строк mysql» в Гугле первой же ссылкой дает описание COUNT(). Так что непонятно, как вы искали.
Что касается улучшений и оптимизации, то улучшать здесь ничего не надо. Надо переписать все полностью.
MAX(`id`) и общее количество посещений — совершенно разные понятия, никак не связанные.
Делать полную выборку (SELECT *) только ради подсчета строк — не самое умное решение, мягко говоря.
Про подключение к mysql из php все написано в документации по самому php, и даже больше, чем здесь.
К чему целая статья на Хабре?
Это не совсем так. Вернее, совсем не так, если говорить о сотрудниках. Статья 1295, п. 2: исключительное право на служебное произведение принадлежит работодателю, если трудовым или гражданско-правовым договором между работодателем и автором не предусмотрено иное.
Большинство заказчиков — специалисты в своем бизнесе, а не в пользовательских интерфейсах и информационной архитектуре. И даже если ваш дизайнер не имеет серьезного опыта проектирования и не обладает большими познаниями в области юзабилити, эти понятия ему ближе, чем директору, скажем, строительной компании. Заставьте этого директора располагать блоки, указывать на необходимое оформление элементов — вы в 99% случаев получаете совершенно не приспособленный к использованию людьми проект. И даже понимание сегментов аудитории, с которой необходимо работать, этому заказчику не сильно поможет.
Пример из жизни: клиент долго доказывал нам, что наиболее важным свойством товаров с точки зрения навигации по каталогу и выбора товара является бренд. Поскольку клиент пытался поступать именно как вы советуете, пришлось тут же обратиться к продавцу в торговом зале с вопросом «Что справшивает покупатель первым делом, когда подбирает нужный товар?». Ответ полностью опроверг утверждение клиента — «А есть у вас [некий_товар] на десятку?» либо «Нужен [некий_товар] размером XX мм»
Другой пример: клиент предоставил все идеальные по его мнению интерфейсы, описание работы каждого элемента системы. Любые попытки что-либо изменить в лучшую сторону отклонялись, поскольку разработчики не специалисты в его сфере и процессах его компании — воспринимаются именно как операторы ПК.
Как вы думаете, кто первым потом плевался и кричал, что работать с этим творением невозможно?
И если бы таких случаев было только два, но они возникают постоянно.
Что касается решения этих проблем вставкой менеджера проекта между дизайнером и клиентом. Менеджер проекта — он все же менеджер. В его компетенции входит управление проектом, а не разработка каждого отдельного компонента этого проекта. Это все же не специалист по интерфейсам и юзабилити, маркетолог и редактор в одном лице.
Заказчик же должен просто объяснить, какие задачи необходимо решить, каких целей необходимо достигнуть (не «хочу меню слева», а «надо увеличить продажи диванов на 20% минимум к сентябрю»). А уже дизайнеры и специалисты в смежных областях пусть думают, как эти задачи решить наиболее эффективно.
Но вот в стартапах, как мне кажется, перебор. Если вы работаете над стартапом, вам нужно как можно быстрее запуститься с минимумом вложений и проверить все свои теории. А иначе есть риск потратить не один месяц на мультиязычность, шардинг БД, все мыслимые и немыслимые API, съесть весь собственный бюджет и все инвестиции (если таковые имелись), а потом окажется, что ваш проект никому не нужен.
К недавней записи можно написать, например, «about 1 hour ago». А в вашем примере вместо 16-часов указать «last morning», или же вовсе для сильно старых записей указывать точное время
Интересный проект. Удачи вам :-)
Это закреплено в соответствующих нормативных актах и в законодательстве РФ.
И мало того, что вы должы получить ISBN-коды (разные для разных носителей), вы еще и обязаны определенное количество копий предоставить в день сдачи тиража в книжную палату, которая распределит эти копии по библиотекам и различным учреждениям. Для простой бумажной книги — 11 копий. Для электронной версии — 3 копии на соответствующих носителях.