На мой взгляд эта книга предназначена точно не для экспертов, а скорее для начинающих.
Для которых эти абстрактные советы и подобные примеры, собранные в одном месте, могут быть весьма полезны.
Но каждый имеет право на своё мнение:)
В целом, если не нравится, то никто не заставляет читать.
С нетерпением буду ждать комментариев про следующие части, но пожалуйста побольше конкретики. С примерами и пояснениями, почему так делать не надо:)
К сожалению, это никакая не книга. Этак и я буду песатель, плодовитый автор бестселлеров.
Отличие книги от этой самодеятельности состоит в том, что у книги всегда есть редактор. И даже не один. Задача которого не пропустить в печать откровенную лажу.
В данном же случае мы имеем по сути стену лифта. Кто хочет — тот и самовыражается. О достоверности сведений можно лишь догадываться.
Обычно такого рода опусы можно разделить условно на две части:
начинают все с абстрактных рассуждений, состоящих из общих мест, с которыми спорить трудно, но и практической пользы никакой извлечь нельзя;
когда же автор переходит к практическим рекомендациям, пытаясь реализовать в коде многочисленные и зачастую противоречашие друг другу рекомендации из теоретической части, чтение становится чревато появлением синяков на лбу и ладони.
С нетерпением жду перевод раздела про инъекции, который с большим удовольствием прокомментирую.
А еще оригинальную библиотеку может купить Oracle, на голову может упасть кирпич, Скайнет может восстать, Роскомнадзор может запретить пользоваться интернетом.
Я предпочитаю решать проблемы по мере их поступления, и — о, чудо! — они решаются. В описанном в статье случае PR принимают фактически мгновенно, транк легко вливается обратно в мой форк, пока это происходит (потому что я умею писать код так, чтобы он мерджился без бубна), и через месяц все возвращается на круги своя.
И каждый раз где-то вокруг находится теоретик «правильного как надо» и выдумывает тысячу мифических причин того, почему все пойдет не так. И пока он с хмурым лицом ходит и рассказывает, что PR могут и не принять, а если и да, то через год, и так далее — все работает, код принимают и все довольны.
Давайте расскажу, как в такой ситуации действую я: со мной такое дважды случалось.
1. fork библиотеки, правка, коммит в свой репозиторий, указание своего репозитория в зависимостях проекта;
2. pull request в trunc;
3. hotfix release у себя;
4. кофе;
5. получение письма о том, что мой pull request принят, переключение обратно.
Если так случается — это большущий минус в карму QA. Я шестнадцать лет работал ведущим разработчиком в небольшой команде из нескольких человек и мы успешно выпускали довольно нетривиальный продукт. Сейчас проект перезапускается и над ним работает команда в несколько десятков человек. Это привело к тому, что каждый разработчик «видит» лишь малую часть проекта, над которой он работает, в результате даже в хорошо покрытый тестами проект просачиваются баги, похожие на описанный. В результате я ушёл из разраба в QA, оставшись консультантом, и теперь моя задача не пропускать такие баги. В этом мне помогает то, что я вижу весь продукт целиком, не вдаваясь в подробности, ну и предыдущий опыт в разработке. Ну и время от времени я сажусь в кресло UAT тестера и «коридорным» методом проверяю — чего там накодили. Кстати, одна из основных проблем бывает доказать менеджерам ещё на этапе тестирования, что такое поведение — это реальный баг (результат-то правильный), потому что драгоценное время на фиксы или доп. разработку тратить не хочется.
Для которых эти абстрактные советы и подобные примеры, собранные в одном месте, могут быть весьма полезны.
Но каждый имеет право на своё мнение:)
В целом, если не нравится, то никто не заставляет читать.
С нетерпением буду ждать комментариев про следующие части, но пожалуйста побольше конкретики. С примерами и пояснениями, почему так делать не надо:)
К сожалению, это никакая не книга. Этак и я буду песатель, плодовитый автор бестселлеров.
Отличие книги от этой самодеятельности состоит в том, что у книги всегда есть редактор. И даже не один. Задача которого не пропустить в печать откровенную лажу.
В данном же случае мы имеем по сути стену лифта. Кто хочет — тот и самовыражается. О достоверности сведений можно лишь догадываться.
Обычно такого рода опусы можно разделить условно на две части:
С нетерпением жду перевод раздела про инъекции, который с большим удовольствием прокомментирую.
ssl.verify_peer в поддерживаемых версия PHP (5.6+) уже по-умолчанию true, и это здорово, ибо очень не многие указывали этот параметр явно
Я предпочитаю решать проблемы по мере их поступления, и — о, чудо! — они решаются. В описанном в статье случае PR принимают фактически мгновенно, транк легко вливается обратно в мой форк, пока это происходит (потому что я умею писать код так, чтобы он мерджился без бубна), и через месяц все возвращается на круги своя.
И каждый раз где-то вокруг находится теоретик «правильного как надо» и выдумывает тысячу мифических причин того, почему все пойдет не так. И пока он с хмурым лицом ходит и рассказывает, что PR могут и не принять, а если и да, то через год, и так далее — все работает, код принимают и все довольны.
Привет.
1. fork библиотеки, правка, коммит в свой репозиторий, указание своего репозитория в зависимостях проекта;
2. pull request в trunc;
3. hotfix release у себя;
4. кофе;
5. получение письма о том, что мой pull request принят, переключение обратно.