В этом классическом примере, разумеется, схожесть текста высокая будет независимо от положения запятой.
Но, как правило, комментарии выглядят несколько более развёрнуто, и перестановка одной-двух заптяых, добавление одного-двух слов не переставляют смысл с ног на голову. :)
А вообще, было бы круто проверять степень изменения текста.
Т.е. если это не опечатку исправили, а изменили смысл (схожесть исходного и конечного текстов комментария низкая), то не разрешать такое сохранять. :)
Зарегистрировался (раза с 5-го из-за возросшего ажиотажа посетителей), нашёл нужную книгу (ещё попыток 15), добавил в корзину (раза с 7-го). Но что-то не могу найти, в каком месте оно бесплатно. Везде фигурируют какие-то суммы денег. :(
Как раз-таки думать там надо меньше, потому что за тебя часто думает система и просто не пропустит ошибку. При работе с NoSQL думать надо гораздо больше, потому что даётся очень много свободы, которая может, при недостаточном продумывании, вылезти, что называется, боком.
> В NoSQL никаких рамок нет, что хочу то ворочу — понятно к чему это приводит
К чему? У нас проект почти 2 года живёт исключительно на MongoDB, и пока всё довольно неплохо. Не без узких мест (что есть, то есть), но не по вине хранилища, честно говоря. Как всегда, всё решают кадры. И на более привычных SQL решениях можно такого нагородить — мало не покажется. :)
Простите, если вопрос наивный, но на каком этапе должен быть проект, чтобы ваша компания могла им заинтересоваться? Рабочий прототип/презентации/прочее, но без покупателей/пользователей, или полноценный продукт, у которого есть потребители и которому нужны инвестиции для роста?
А что в данном случае значит «засыпались»? Тут же не оценки ставят, а определяют некоторый тип. И если вы, предположим, просто не знаете, как работать с представителями различных менталитетов, значит и отвечаете именно так, как поступили бы на самом деле, что вполне объективно охарактеризует ваше умение договариваться. Мне кажется, ошибки тут нет.
«прокуратурою»,
«касалося»,
«жмякнул мышóю»,
«В позавчерашнем сообщении ИА «Тема Казань» нетрудно прочесть»,
«у кадра из штатовского кинофильма»,
«распространял-де»,
«татуирован изображением»,
«Для не смотревших уместно поведать заодно, что основная мысль, основная идея этой кинокартины является скорее антирасистскою, хотя в ней и показан — наглядно и натуралистически — целый ряд преступлений междурасового характера, совершаемых чёрными против белых и белыми против чёрных.» — это предложение вообще великолепное
Мне в одном известном московском магазине 5 лет назад пытались продать БУшный (или витринный) MacBook (ещё белый, пластиковый) под видом нового. Т.е. я оплатил на кассе, мне принесли коробку, я при них её вскрыл и увидел, что весь (ВЕСЬ! т.е. и сверху и снизу) пластик корпуса исцарапан, ножки снизу грязные, а экран заляпан. Попросил принести новый, а мне сказали, что это был последний и отказывались возвращать уплаченные деньги. После угрозы обратиться в Страсбургский суд КЗПП деньги всё-таки вернули.
Написать-то можно, только вот помочь они не смогут. Я тоже хотел как–то сменить ник здесь, но служба поддержки прислала отказ, сославшись на техническую невозможность данной операции.
Ну, при физическом доступе к серверу, вроде как, можно получить над ним управление (точно сказать не могу, не моя епархия), так что отправили бы свеженанятого админа в датацентр разбираться в ситуации и решать проблемы. :)
Касательно ssh-ключей, ситуация, на мой взглят, двоякая. Существует вероятность в какой–то момент просто остаться без доступа к серверам.
Была у нас как–то ситуация: админ компании сначала ушёл в отпуск, а после отпуска просто исчез. Дозвониться или как–то ещё выйти на контакт не удавалось. Все доступы к серверам на площадках были у него, а авторизовывался он там через ключи (грубо говоря, запускал в консоли скрипт типа connect some_server), чтобы не вводить постоянно пароли.
И вот исключительно благодаря этим ключам, отыскав пароль к его рабочей машине мы смогли от его имени войти на сервера и получить к ним полный доступ. С одной стороны, это, конечно, было хорошо для нас, а вот с другой — огромная дыра в безопасности.
Я за хранение паролей в зашифрованном менеджере паролей и за ввод их каждый раз при авторизации.
Да там и увеличение нагрузки–то будет только в том случае, если нет ограничения на количество выводимых результатов, потому как по своей сути запрос вида 'LIKE "%"' ничем не отличается для базу от запроса 'LIKE "%some%words%"'.
Насчёт второго аргумента соглашусь условно. В том смысле, что ничего криминального не вижу в том, чтобы отдать пользователю всё и сразу, раз он так захотел — пусть сам роется или сужает рамки поиска вводом адекватных критериев, но если логика приложения к такому не готова, то это, наверное, плохо. :)
LIKE, как правило, используется в запросах для поиска по сайту и прочего подобного функционала, где нужен именно нечёткий поиск с возвратом большого количества результатов, поэтому, имхо, большой беды в том, что Вы написали нет. За исключением, наверное, тех случаев, когда сервер не сможет обработать запрос ввиду чрезмерно большого количества результатов и скрипт выдаст ошибку, содержащую некоторое количество информации о структуре БД (теоретически, большое количество таких запросов может нейтрализовать нормальную работу сайта).
Но это уже вопрос, скорее, к настройкам сервера и перехвату ошибок, чтобы не показать пользователю то, что видеть ему не следует.
У Вас «супергерой шутник» в какой–то негативной коннотации приведено. :)
Так или иначе, если собеседование предполагает тестирование на месте, у меня есть простой тест на знание PHP и MySQL, через который я сам когда–то проходил при приёме на работу разработчиком. Тест простейший (делается за 10–15 минут), но за последние 5 лет его использования не дал ни одной осечки: на прошлом месте работы все разработчики, которые его выполняли, были приняты на работу и отлично себя проявляли.
Но в последнее время уже и тестов не требуется, как правило: достаточно послушать, как и что человек рассказывает о задачах, которые ему приходилось решать, и можно, в общем–то, получить достаточное представление о его квалификации и вменяемости.
Отличная штука. :) Пусть как можно больше чуваков её вызубрят, можно будет легко таких отсеивать на собеседованиях. Например, в вопросе #22, где используется strlen(), можно тестируемому подсунуть кириллическую строку в UTF-8 и посмотреть, как он удивится, когда заученный пример отработает некорректно. :)
Приходилось собеседовать довольно много разработчиков, и основываясь на своём опыте могу сказать, что хороших рарзработчиков удавалось найти и без таких вопросов. :)
Но, как правило, комментарии выглядят несколько более развёрнуто, и перестановка одной-двух заптяых, добавление одного-двух слов не переставляют смысл с ног на голову. :)
Т.е. если это не опечатку исправили, а изменили смысл (схожесть исходного и конечного текстов комментария низкая), то не разрешать такое сохранять. :)
Или это уже реализовано?
— Тут мог быть комментарий совсем другого содержания, нивелирующий смысл сообщения ответившего мне комментатора. :)
Как раз-таки думать там надо меньше, потому что за тебя часто думает система и просто не пропустит ошибку. При работе с NoSQL думать надо гораздо больше, потому что даётся очень много свободы, которая может, при недостаточном продумывании, вылезти, что называется, боком.
> В NoSQL никаких рамок нет, что хочу то ворочу — понятно к чему это приводит
К чему? У нас проект почти 2 года живёт исключительно на MongoDB, и пока всё довольно неплохо. Не без узких мест (что есть, то есть), но не по вине хранилища, честно говоря. Как всегда, всё решают кадры. И на более привычных SQL решениях можно такого нагородить — мало не покажется. :)
У меня эти приложения ещё с субботы отображались (раньше просто не проверял), а это всё-таки «позавчера» как минимум. :)
В этот же раз опубликована чудовищная мешанина стилей изложения и местами вообще какая-то абракадабра. :(
«прокуратурою»,
«касалося»,
«жмякнул мышóю»,
«В позавчерашнем сообщении ИА «Тема Казань» нетрудно прочесть»,
«у кадра из штатовского кинофильма»,
«распространял-де»,
«татуирован изображением»,
«Для не смотревших уместно поведать заодно, что основная мысль, основная идея этой кинокартины является скорее антирасистскою, хотя в ней и показан — наглядно и натуралистически — целый ряд преступлений междурасового характера, совершаемых чёрными против белых и белыми против чёрных.» — это предложение вообще великолепное
Вы хоть сами читали это перед публикацией? :(
Страсбургский судКЗПП деньги всё-таки вернули.Была у нас как–то ситуация: админ компании сначала ушёл в отпуск, а после отпуска просто исчез. Дозвониться или как–то ещё выйти на контакт не удавалось. Все доступы к серверам на площадках были у него, а авторизовывался он там через ключи (грубо говоря, запускал в консоли скрипт типа connect some_server), чтобы не вводить постоянно пароли.
И вот исключительно благодаря этим ключам, отыскав пароль к его рабочей машине мы смогли от его имени войти на сервера и получить к ним полный доступ. С одной стороны, это, конечно, было хорошо для нас, а вот с другой — огромная дыра в безопасности.
Я за хранение паролей в зашифрованном менеджере паролей и за ввод их каждый раз при авторизации.
Насчёт второго аргумента соглашусь условно. В том смысле, что ничего криминального не вижу в том, чтобы отдать пользователю всё и сразу, раз он так захотел — пусть сам роется или сужает рамки поиска вводом адекватных критериев, но если логика приложения к такому не готова, то это, наверное, плохо. :)
Но это уже вопрос, скорее, к настройкам сервера и перехвату ошибок, чтобы не показать пользователю то, что видеть ему не следует.
Так или иначе, если собеседование предполагает тестирование на месте, у меня есть простой тест на знание PHP и MySQL, через который я сам когда–то проходил при приёме на работу разработчиком. Тест простейший (делается за 10–15 минут), но за последние 5 лет его использования не дал ни одной осечки: на прошлом месте работы все разработчики, которые его выполняли, были приняты на работу и отлично себя проявляли.
Но в последнее время уже и тестов не требуется, как правило: достаточно послушать, как и что человек рассказывает о задачах, которые ему приходилось решать, и можно, в общем–то, получить достаточное представление о его квалификации и вменяемости.
Приходилось собеседовать довольно много разработчиков, и основываясь на своём опыте могу сказать, что хороших рарзработчиков удавалось найти и без таких вопросов. :)