Вы сами-то пробовали её читать? Основное содержание составляют любование обнажённой натурой и "реконструкции" влажных фантазий о юном переписчике, попавшем в малинник. А инженерные анализы тут сбоку припёка.
Я понимаю - возраст такой, хочется чего-то волнующего, неизведанного. Но надо определиться. Или "инженерный анализ", или "реконструкции" и в Читальный зал.
Кстати, кто догадается, что имеется в виду в нижеприведенном сложносочиненном предуведомлении - тому приз
До PHP 8.0 уровень отчетности об ошибках по умолчанию начинался с E_ALL, а затем явно удалялись диагностические уведомления (E_NOTICE), строгие предупреждения о типах (E_STRICT) и уведомления об устаревании (E_DEPRECATED).
(тут в первую очередь заслуга косноязычного автора, переводчик лишь старательно скопировал эту белиберду).
Я даже не знаю, кто здесь прекраснее - никому неизвестный Эрик А. Манн, который пишет книги "на отвали", или обкурившийся школьник, который его переводил.
Этот "инженер-программист" выступает в роли прапорщика из анекдота, "Летают, только низенько-низенько". Сначала он пишет рецепт, что на боевом сервере все ошибки надо подавить. А потом при обсуждении вдруг вспоминает, что вообще-то не надо. Так надо или нет? Вроде не мальчик, мог бы определиться уже, за столько-то лет разработки.
Или совершенно бессмысленные примеры кода, на которые смотришь и думаешь - "а нафига вообще в язык завезли такой дурацкий функционал? Я что - сам не выведу сообщение об ошибке, без всяких исключений?"
Ну и самая знаменитая бессмыслица, куда же без неё: "Вы знаете, что функция может выдать ошибку, поэтому важно обернуть любой ее вызов в оператор try". Ага, то-то я вижу каждый вызов require, или любой оператор деления обёрнутый в try... А обрабатывать пойманное исключение автор рекомендует фразой "у вас тут бешеный суслик". Просто прелестно. представляю код, написанный по этим рецептам.
Но окончательно книгу испортил, конечно, двоечник, которого заставили переводить незнакомые слова. И сэкономившее на техническом редакторе издательство. Что надо курить, чтобы простую фразу
There might be specific pages with known errors
превратить в нелепую отсебятину
Возможно, существуют страницы с записями об уже известных ошибках
?
Кто должен следить, чтобы из текста не пропадало форматирование, и непереводимые термины
Any other Error or Exception thrown by the function
не стали простым текстом, полностью меняющим смысл,
Любая другая ошибка или исключение будут перехвачены
Пенять на SO не странно. У них на заглавной странице написано, что они мечтают стать "библиотекой детальных высококачественных ответов на любой вопрос по программированию". А по факту стали кладбищем, утыканным памятникам людской спеси. С редкими исключениями из этого правила.
Кроме того, SO задумывался как расширение документации. Часто бывает так, что человек прочел документацию, но ничего не понял. В задачу документации не входит разжёвывание. В частности, наличие отдельной странички, где перечисляются все варианты использования того или иного символа. Но для этого подходит Stack Overflow. И в данном случае, ценой некоторых усилий, он выполняет эту свою функцию.
Но вот надеяться, что это будет верно для всех остальных случаев - увы, нельзя.
Ну это как раз не принципиально. Первая, пятая - главное чтобы была. А тут как раз проблема в том, что в документации нет единой страницы, которая объясняла бы все варианты, и приходится смотреть по другим источникам.
Не очень понятно, зачем вы решили поделиться со мной этой информацией, но раз уж мы все равно здесь, то два уточнения:
Во-первых, это не совсем та документация. Если, скажем, в работу этого оператора будут внесены изменения, то на этой странице их никто править не будет. Документация на оператор (а не описание нововведений определенной версии языка) - это, скорее, здесь (и вот эту страницу вам гугль покажет куда менее охотно, увы).
Во-вторых, по очевидным причинам на этой странице рассматриваются только два механизма. А я говорил о трёх. И документация на третий находится гуглем только если заранее знать, как он называется. Что превращает поиски в замкнутый круг.
Еще один загадочный оператор в РНР - это троеточие. Он используется для реализации трёх различных механизмов, причем если первые два хотя бы очень близкие, то третий к ним не относится вообще никак.
И здесь мы сталкиваемся с очень большой проблемой Stack Overflow (и - как следствие - чат жипити): этот сайт напоминает кладбище, ответы на котором напоминают замшелые монументы, возведенные в незапамятные времена. Сама идея такого Q&A сайта изначально порочна: механизма редактирования информации (как например в википедии) не предусмотрено. Да, можно написать свой новый ответ. Который никто не увидит в самом низу длинного списка реплик, написанных при царе Горохе.
При этом элементарные правила юзабилити требуют одного нормального, подробного и полного ответа в самом верху. А не копания в разрозненных заметках разной степени неграмотности. И вполне логично было бы дополнить топовый ответ. Но здесь ты сталкиваешься с самыми распрекрасными человеческими качествами - самолюбием и спесью. Кто-то благосклонно принимает правки, кто-то - к счастью - давно забыл про этот сайт, но большинство авторов ответов очень ревниво относятся к попыткам улучшить или обновить информацию. Плюс правила явно запрещают существенные правки, разрешая только стилистические.
Хорошей иллюстрацией всех этих проблем как раз является вопрос про три точки. Самый топовый ответ является и самым бесполезным, а чтобы сподвигнуть хотя бы автора следующего за ним ответа на изменения, пришлось изрядно потрудиться.
Интересный случай когда оба правы. You know, I'm something of a technical writer myself, и очень люблю таких зануд как комментатор выше. Сам-то всегда смотришь только с одной точки зрения, и требуется вторая пара глаз, чтобы подметить кошмар техписа - место, в котором тебя могут понять неправильно :)
Хотя у вас конечно пограничный случай - по тексту и так ясно, что речь идёт именно о чтении. А неверная трактовка возникает только если вырвать фразу из контекста. Но опять же, по опыту - люди читают по такой диагонали, что я стараюсь по возможности избегать даже таких разночтений.
Один из самых показательных примеров (раз уж мы в хабе про РНР) - это страничка документации про генераторы. Примерно 80% пхпешников после её прочтения остаются в убеждении, что генераторы служат для экономии памяти. Читая приведенный ниже абзац,
Генератор помогает писать код, который использует foreach для перебора набора данных без необходимости создания массива в памяти
они по какой-то неведомой причине проскакивают середину и воспринимают это предложение как "Генератор помогает писать код без необходимости создания массива в памяти". И получают на 100% некорректное утверждение: код, который не требует создания массива в памяти, реализуется совсем другими механизмами. А генератор всего лишь позволяет "поженить" эти механизмы с командой foreach.
Увы, добиться изменения этой формулировки нереально - если читать её целиком, то она на 100% корректна и менять её никто не будет. И при этом большиство понимает её неправильно. Такой вот интересный феномен.
@Beeline_tech неужели дела компании Билайн настолько плохи, что на редактора денег нет совсем? Который хотя бы подчистил за переводившим статью школьником несогласованные предложения. А в идеале проводил отбраковку исходно корявых статей и в целом проверял соответствие заголовка бессвязному нагромождению фактов внутри.
Спасибо, статья выглядит очень добротно. Ну и сама идея придумать сфинкс на коленке вызывает уважение.
Но кстати, интересно было бы узнать, как именно должны подключаться настоящие поисковики. В факе написано как-то очень обтекаемо,
Large sites may be better off with a dedicated standalone search engine, such as Solr, rather than the pure-PHP implementation used in Smart Search
но вроде бы подразумевается, что это будет совсем отдельный движок. А для меня логичным было бы встроить их поддержку в плагин напрямую. По идее это было бы самым правильным решением: поначалу испльзуем самопал на mysql, а когда выросли - поставили эластик и просто переключили плагин чтобы он начал работать не со своими таблицами, а с внешним поисковым движком.
Сосеть, конечно. Как и предсказывал Иван Роганов, Хабр очень быстро скатился до низкопробной СММ-площадки. Технический контент - это рудимент. Его уже почти не пишут и не читают. Количество просмотров технических статей упало катастрофически. Те, кто читали их раньше, уходят из-за атмосферы ярмарочного балагана. А новым пользователям подавай развлекуху, и их герой - Слава Рюмин, с его опусами "мне Рабинович напел".
К сожалению, ваш комментарий такой же спорный, как и заявления в статье, с кторыми вы дискутируете. Что сильно его обесценивает.
90% рынка было в 90-х 2000-х, и те времена давно прошли.
Общего назначения он только в теории, на практике это веб-онли.
Настоящих специалистов по РНР действительно ждут везде и за любые деньги, но зачастую чтобы переучить на Go. Скажем, ко мне половина рекрутеров стучатся именно с вакансиями PHP/Go.
Я согласен с вами, что в статье написана чушь, буквально взаимоисключающие параграфы:
Сейчас можно порекомендовать Ruby..., потому что технология начала умирать
Тут конечно немного вырвано из контекста, но по факту абзац звучит именно так.
или "Во фрилансе самыми востребованными являются РНР и JS", но РНР язык непопулярный. Это как?
Так что да, вместо Руби вполне стоило бы поставить РНР, просто потому что на нем легче найти джниорскую позицию, хоть на 1С, хоть на уородпрес, хоть на галеры.
Но при этом и нарисованная вами картина тоже далека от реальности.
По моим ощущениям, на Go переписывают узкие места, а круды как клепали так и клепают на ларавле. И я честно не вижу смысла писать всю админку большого екома на Го, когда ларавля даёт сто очков вперед по производительности процесса разработки.
Как вы яхту назовёте, так она и поплывёт. В культовом фильме героя зовут Чингачгук - большой шланг.
Я так понял что по опыту вождь Большая Печаль скорее фуллстек. Почему бы не поискаться на эти вакансии? Да, галеры, но по фуллстеку-ж опыта больше, чем по чисто фронту.
Сами по себе цифры совпадают с предыдущим подходом к снаряду. Но постить на Хабр огрызок статьи с подписью остальное читайте в наш телеграм канал - это фе.
Вы сами-то пробовали её читать? Основное содержание составляют любование обнажённой натурой и "реконструкции" влажных фантазий о юном переписчике, попавшем в малинник. А инженерные анализы тут сбоку припёка.
Я понимаю - возраст такой, хочется чего-то волнующего, неизведанного. Но надо определиться. Или "инженерный анализ", или "реконструкции" и в Читальный зал.
Кстати, кто догадается, что имеется в виду в нижеприведенном сложносочиненном предуведомлении - тому приз
(тут в первую очередь заслуга косноязычного автора, переводчик лишь старательно скопировал эту белиберду).
Я даже не знаю, кто здесь прекраснее - никому неизвестный Эрик А. Манн, который пишет книги "на отвали", или обкурившийся школьник, который его переводил.
Этот "инженер-программист" выступает в роли прапорщика из анекдота, "Летают, только низенько-низенько". Сначала он пишет рецепт, что на боевом сервере все ошибки надо подавить. А потом при обсуждении вдруг вспоминает, что вообще-то не надо. Так надо или нет? Вроде не мальчик, мог бы определиться уже, за столько-то лет разработки.
Или совершенно бессмысленные примеры кода, на которые смотришь и думаешь - "а нафига вообще в язык завезли такой дурацкий функционал? Я что - сам не выведу сообщение об ошибке, без всяких исключений?"
Ну и самая знаменитая бессмыслица, куда же без неё: "Вы знаете, что функция может выдать ошибку, поэтому важно обернуть любой ее вызов в оператор try". Ага, то-то я вижу каждый вызов require, или любой оператор деления обёрнутый в try... А обрабатывать пойманное исключение автор рекомендует фразой "у вас тут бешеный суслик". Просто прелестно. представляю код, написанный по этим рецептам.
Но окончательно книгу испортил, конечно, двоечник, которого заставили переводить незнакомые слова. И сэкономившее на техническом редакторе издательство. Что надо курить, чтобы простую фразу
превратить в нелепую отсебятину
?
Кто должен следить, чтобы из текста не пропадало форматирование, и непереводимые термины
не стали простым текстом, полностью меняющим смысл,
поскольку ошибки этот код ловить не будет?
Пенять на SO не странно. У них на заглавной странице написано, что они мечтают стать "библиотекой детальных высококачественных ответов на любой вопрос по программированию". А по факту стали кладбищем, утыканным памятникам людской спеси. С редкими исключениями из этого правила.
Кроме того, SO задумывался как расширение документации. Часто бывает так, что человек прочел документацию, но ничего не понял. В задачу документации не входит разжёвывание. В частности, наличие отдельной странички, где перечисляются все варианты использования того или иного символа. Но для этого подходит Stack Overflow. И в данном случае, ценой некоторых усилий, он выполняет эту свою функцию.
Но вот надеяться, что это будет верно для всех остальных случаев - увы, нельзя.
Для полноты картины, двойная стрелочка также используется
в конструкции foreach, когда мы хотим получить не только значение, но и ключ.
в выражении match
В случае РНР таких проблем не возникает. Во всех приведенных здесь ссылках фигурирует только официальная.
Ну это как раз не принципиально. Первая, пятая - главное чтобы была. А тут как раз проблема в том, что в документации нет единой страницы, которая объясняла бы все варианты, и приходится смотреть по другим источникам.
Не очень понятно, зачем вы решили поделиться со мной этой информацией, но раз уж мы все равно здесь, то два уточнения:
Во-первых, это не совсем та документация. Если, скажем, в работу этого оператора будут внесены изменения, то на этой странице их никто править не будет. Документация на оператор (а не описание нововведений определенной версии языка) - это, скорее, здесь (и вот эту страницу вам гугль покажет куда менее охотно, увы).
Во-вторых, по очевидным причинам на этой странице рассматриваются только два механизма. А я говорил о трёх. И документация на третий находится гуглем только если заранее знать, как он называется. Что превращает поиски в замкнутый круг.
Еще один загадочный оператор в РНР - это троеточие. Он используется для реализации трёх различных механизмов, причем если первые два хотя бы очень близкие, то третий к ним не относится вообще никак.
И здесь мы сталкиваемся с очень большой проблемой Stack Overflow (и - как следствие - чат жипити): этот сайт напоминает кладбище, ответы на котором напоминают замшелые монументы, возведенные в незапамятные времена. Сама идея такого Q&A сайта изначально порочна: механизма редактирования информации (как например в википедии) не предусмотрено. Да, можно написать свой новый ответ. Который никто не увидит в самом низу длинного списка реплик, написанных при царе Горохе.
При этом элементарные правила юзабилити требуют одного нормального, подробного и полного ответа в самом верху. А не копания в разрозненных заметках разной степени неграмотности. И вполне логично было бы дополнить топовый ответ. Но здесь ты сталкиваешься с самыми распрекрасными человеческими качествами - самолюбием и спесью. Кто-то благосклонно принимает правки, кто-то - к счастью - давно забыл про этот сайт, но большинство авторов ответов очень ревниво относятся к попыткам улучшить или обновить информацию. Плюс правила явно запрещают существенные правки, разрешая только стилистические.
Хорошей иллюстрацией всех этих проблем как раз является вопрос про три точки. Самый топовый ответ является и самым бесполезным, а чтобы сподвигнуть хотя бы автора следующего за ним ответа на изменения, пришлось изрядно потрудиться.
Интересный случай когда оба правы. You know, I'm something of a technical writer myself, и очень люблю таких зануд как комментатор выше. Сам-то всегда смотришь только с одной точки зрения, и требуется вторая пара глаз, чтобы подметить кошмар техписа - место, в котором тебя могут понять неправильно :)
Хотя у вас конечно пограничный случай - по тексту и так ясно, что речь идёт именно о чтении. А неверная трактовка возникает только если вырвать фразу из контекста. Но опять же, по опыту - люди читают по такой диагонали, что я стараюсь по возможности избегать даже таких разночтений.
Один из самых показательных примеров (раз уж мы в хабе про РНР) - это страничка документации про генераторы. Примерно 80% пхпешников после её прочтения остаются в убеждении, что генераторы служат для экономии памяти. Читая приведенный ниже абзац,
они по какой-то неведомой причине проскакивают середину и воспринимают это предложение как "Генератор помогает писать код без необходимости создания массива в памяти". И получают на 100% некорректное утверждение: код, который не требует создания массива в памяти, реализуется совсем другими механизмами. А генератор всего лишь позволяет "поженить" эти механизмы с командой foreach.
Увы, добиться изменения этой формулировки нереально - если читать её целиком, то она на 100% корректна и менять её никто не будет. И при этом большиство понимает её неправильно. Такой вот интересный феномен.
@Beeline_tech неужели дела компании Билайн настолько плохи, что на редактора денег нет совсем? Который хотя бы подчистил за переводившим статью школьником несогласованные предложения. А в идеале проводил отбраковку исходно корявых статей и в целом проверял соответствие заголовка бессвязному нагромождению фактов внутри.
Интересный тип продукции...
Спасибо, статья выглядит очень добротно. Ну и сама идея придумать сфинкс на коленке вызывает уважение.
Но кстати, интересно было бы узнать, как именно должны подключаться настоящие поисковики. В факе написано как-то очень обтекаемо,
но вроде бы подразумевается, что это будет совсем отдельный движок. А для меня логичным было бы встроить их поддержку в плагин напрямую. По идее это было бы самым правильным решением: поначалу испльзуем самопал на mysql, а когда выросли - поставили эластик и просто переключили плагин чтобы он начал работать не со своими таблицами, а с внешним поисковым движком.
Начинаешь читать и думаешь - какое счастье, что весь этот ужас прошел мимо тебя. А потом такой - "что, оно ещё и на базе уордпресс?!"
Сосеть, конечно. Как и предсказывал Иван Роганов, Хабр очень быстро скатился до низкопробной СММ-площадки. Технический контент - это рудимент. Его уже почти не пишут и не читают. Количество просмотров технических статей упало катастрофически. Те, кто читали их раньше, уходят из-за атмосферы ярмарочного балагана. А новым пользователям подавай развлекуху, и их герой - Слава Рюмин, с его опусами "мне Рабинович напел".
К сожалению, ваш комментарий такой же спорный, как и заявления в статье, с кторыми вы дискутируете. Что сильно его обесценивает.
90% рынка было в
90-х2000-х, и те времена давно прошли.Общего назначения он только в теории, на практике это веб-онли.
Настоящих специалистов по РНР действительно ждут везде и за любые деньги, но зачастую чтобы переучить на Go. Скажем, ко мне половина рекрутеров стучатся именно с вакансиями PHP/Go.
Я согласен с вами, что в статье написана чушь, буквально взаимоисключающие параграфы:
Тут конечно немного вырвано из контекста, но по факту абзац звучит именно так.
или "Во фрилансе самыми востребованными являются РНР и JS", но РНР язык непопулярный. Это как?
Так что да, вместо Руби вполне стоило бы поставить РНР, просто потому что на нем легче найти джниорскую позицию, хоть на 1С, хоть на уородпрес, хоть на галеры.
Но при этом и нарисованная вами картина тоже далека от реальности.
По моим ощущениям, на Go переписывают узкие места, а круды как клепали так и клепают на ларавле. И я честно не вижу смысла писать всю админку большого екома на Го, когда ларавля даёт сто очков вперед по производительности процесса разработки.
Зачем тогда вообще влезать, если лично вы команду
awkзапустить не можете?Как вы яхту назовёте, так она и поплывёт. В культовом фильме героя зовут Чингачгук - большой шланг.
Я так понял что по опыту вождь Большая Печаль скорее фуллстек. Почему бы не поискаться на эти вакансии? Да, галеры, но по фуллстеку-ж опыта больше, чем по чисто фронту.
Сами по себе цифры совпадают с предыдущим подходом к снаряду. Но постить на Хабр огрызок статьи с подписью остальное читайте в наш телеграм канал - это фе.