Это все да, но у GET, к слову, есть конкретное назначение. Вообще, GET - это же не аббривеатура. Это вполне себе слово. Точно описывающее суть этого запроса. Ссылки с параметрами позволяют пользователям делиться ими между собой, гарантируя одинаковость отображения, например. Когда интернет стал из статичного превращаться в динамический, оказалось, что без параметризованных адресов далеко не уехать. Так что GET не зло. Но надо его использовать там, где он нужен. Есть простое правило - используй GET для readOnly операций и все будет хорошо. Всегда.
Я и не говорил что гет - зло. Но к конкретному случаю, по твоему описанию, гет не имеет никакого отношения. Мне же не надо делиться с друзьями своими ошибками) Тем более что это ошибки одноразовые. Понятно что если надо передать ссылку с уже встроенными переменными, то без гета никуда. По крайней мере, я сомневаюсь что существует другой способ.
Это да. Но вся соль в том, что так проще. Думаю, это основная причина, почему так делают, в том числе, интернет-гиганты. меньше кода, проще его логика. Чисто меркантильные соображения.
@Fell-x27 в общем я не смог удержаться, ну вот не люблю учиться как нормальные люди и читать книжки и видосики смотреть и потому решил попрактиковаться. тут решение Собственно если будет желание посмотреть я только за любую критику. С психикой у меня все хорошо, потому слова можно не подбирать . Собственно мне никогда за php не платили, как и за сервер сайд в целом (раве что мелкие задачки внутри какого -то проекта). Php я не знал и успел забыть Мнение интересно с точки зрения того, куда идти. В чем проблемы. И поскольку я человек меркантильный, то конечно интересует монетизация скила и ответ на вопрос -что нужно "доделать", чтобы претендовать на работу php developer -ом. p.s. сразу скажу что это для меня был реально взрыв мозга, очевидные вещи для клиента пришлось придумывать как сделать без js... Понимание, что даже без знаний php эту задачу я бы без сомнения решил за 1-2 часа и в соответствии с рекомендациями фреймворка(думаю любого), т.е. правильно для большинства кейсов, угнетало. Но пришлось пофантазировать и сам процесс мне понравился В общем как получилось, в конце рабочего дня под интересное кино пути рефакторинга не искал...
ну раз работает и основные проверки есть, то задача выполненна и хорошо. Вроде по ходу чтения все понятно, но в голове столько шагов держать трудно, без пузыря не разберусь. Как поддерживать процедурный код еще и без комментариев я хз Пока дошел до 30 строчки, забыл что в 1 было Но ничего раздражающего не увидел, для меня проблема только в том, как тут тесты писать и кто поддерживать будет По остальному я ничего не скажу, нет у меня навыков в "бест практиках" и того, как правильно всеравно незнаю ))) Но я бы почитал http://getjump.me/ru-php-the-right-way/ Сколько времени примерно делал?
Насчёт процедурного кода - не было у меня ещё такой ситуации, где без ООП я бы не справился, да, местами бывает удобнее использовать ООП, но не всегда. А насчёт комментариев - ты полностью прав. Надо завести привычку их писать. Даже если проект лично мой и никому он больше нафиг не нужен. --- Добавлено --- А вот этого не понял, разъясни, если нетрудно.
хм. Ну вот как минимум - попробуй написать к этому коду тесты или добавь тут возможность загрузки изображений (можно драг н дроп любой либой) и поймешь зачем тебе ООП. А остальное мне трудно судить, лично мне ООП больше знакомо, чем php Сколько времени потратил на него? p.s. по поводу тестов. Ну вот смотри я у себя специально делал отдельно клас юзера и работы с базой, чтобы были зависимости и проверки типов. В тестах я могу проверить все ли ок просто создав объект. Далее используется фасад, чтобы лишнее убрать и оставить в доступе только те методы, которые используются в идеале скрывая логику остальную, тут тоже тесты писать легко, ну и т.д., типо подобия фабрики, чтобы в разных кейсах создавать объект фасада, что отлично тестируется и т.п.... php unit подключается 1 командой в терминале и добавлением неймспейса. А вот как ты процедурный код тестрировать будешь ? )
Как бы работаю, но как бы играюсь. Хочется начать зарабатывать, только стрёмно проект брать. А вдруг не справлюсь. Что заказчику скажу. Да и где этого заказчика найти? Скажем так, я не полностью уверен в своих силах
я за первый проект брался на odesk, у чувака wordpress лежал. Знаний было 0. Погуглил часик, часа 2 потыкал... $50, все. работая с пиндосами понял простую истину -продавать нужно не то, что у тебя есть, а то, что нужно заказчику, это закон. Проект который ты не сможешь сделать тебе не дадут. Просто смотри чтобы заказчик был с историей.
Как бы работаю, но как бы играюсь. Хочется начать зарабатывать, только стрёмно проект брать. А вдруг не справлюсь. Что заказчику скажу Скажем так, я не полность Для работы с юзером, и другими таблицами из БД, и связи с ними у меня обычну несколько функций, а для базы - стандартная конструкция $db->connect ($host,$user, $pass, $dbname); - тоже, от части ООП) --- Добавлено --- Уже, наверное месяц пытаюсь собраться с мыслями, но всё никак не соберусь. То учёба мешает, то работа, то по бухать хочется, то ещё какая история вырисовывается Попробую посмотреть на oDesk. Спасибо за совет.
он недавно стал upwrok А то, что мешает, лучше забить, чем дальше, тем больше мешать будет. Теме мастер Йода придумавший сие задание что сказал? скорее всего -ты справился, значит ты уже папка и пора деньгу зашибать ))))
А можно выложить на сервер уже рабочую собранную версию? Мне, как и многим другим, будет крайне влом у себя разворачивать.
Ды просто на хостинге разверни, чтобы по ссылке доступно было как сайт. Зачем усложнять простые вещи Это именно чтобы потыкать. Кодревью - он потом.
стартовать иногда не сразу может, а так должно работать - https://afternoon-lake-25210.herokuapp.com/ Но это как бы не законченное приложение, просто по таскам )) я правда немного ошибкок возвращаемых для отладки оставил, но мешать не должны. )) p.s. и да после переноса темы я ее таки увидел и это уже прочитал ( в ТЗ кнопки таки. И не просто так Попробуй перепилить на них. ) Ну и да, там в .ini данные подключения к базе и они в репозитории, то сделанно осознанно, в принципе ничего не мешает на heroku установить их в окружении, просто лень. там воркер вечно работать не будет и от использования этой базы будет бльше гемороя чем профита, потому если что -на здоровье
Ревью "от заказчика": 1) Запили страничку, посередине которой форма входа с полями под логин и пароль. 2) Под ней кнопки "зарегаться" и "войти". 5) Если все ок, то, форма меняется на огромное число "0", а кнопки меняются на "+1" и "Выход". Краное - это то, что не принято. Кроме этого, то же замечание, что и у предыдущего исполнителя - использование input date: По коду: 1) Слишком избыточен для такой задачи. Плюс ООП ради ООП, бессмысленно и беспощадно. Там, где он, на самом деле не нужен. По крайней мере не настолько избыточный. 2) Слишком усложнен для такой задачи. Хоть вроде и ООП, которое должно привносить порядок и логику, на деле имеем ультрасвязное спагетти. Для того, чтобы вытащить одну переменную, местами отрабатывает целая связка однострочных методов в совершенно разных файлах, из-за чего логика кода воспринимается очень тяжело. Я как будто монстра из нескольких десятков тысяч строк изучал, а не задачку, решаемую за вечер. 3) Использование "Worker" в названиях сбивает толку из-за наличия в php вот такой штуки. 4) Так делать не надо: PHP: public static function cleanUpInput($value) { return strip_tags(htmlspecialchars(trim($value))); } Сначала ты делаешь трим, ок, допустим, потом делаешь htmlspecialchars, что уже, по-факту, порча данных, потому что пользователь вводил не это. Потом, поверх накатываем strip_tags, что, во-первых варварство и порча данных, потому что режет их не думая, а во-вторых это не имеет смысла, потому что htmlspecialchars, у нас уже отработал валидного HTML в строке уже в принципе нет. Это при том, что этот "метод защиты" никак не защищает ни от каких инъекций. Серьезно. Из этого всего смысл имеет только htmlspecialchars, но не на входе, а на выводе информации. 5) Считай это продолжением пункта 4 - у тебя в коде SQL-инъекции. Твоя фильтрация из пункта 4 никак от них не защищает, только коцает вводимые данные, которые ничем базе и не были опасны. ТЫ используешь PDO, но я нигде не нашел у тебя ни одного вызова PDO->prepare(); Зато полным полно запросов вида: PHP: INSERT INTO `users` (`login`, `password`, `age`, `counter`) VALUES ('$login', '$password', '$age', 0) Где данные вставляются в запрос "как есть". Это плохо. Выбор PDO, в таком случае, тоже странен. Но это уже твое личное дело. 6) Странная логика фильтрации данных PHP: Helpers::cleanUpInput($login), password_hash(Helpers::cleanUpInput($password), PASSWORD_DEFAULT) Ты кусачками кромсаешь логин пароль, внося в них изменения, между прочим. Вот тебе пример, почем это плохо - если у пользователя пароль "<fhg2711341>q", ты его весело и безмятежно превращаешь в "q". Сложный, несловарный трудноподборный пароль превратился в одну буковку. Можешь сам проверить. 7) К слову об архитектуре и избыточности кода: PHP: if(func_num_args() == 2) { $this->facade = new WorkerFacade( // used in login form handling new User( Helpers::cleanUpInput($login), password_hash(Helpers::cleanUpInput($password), PASSWORD_DEFAULT) ), new DBHelper() ); } else { $this->facade = new WorkerFacade( // used in registration form handling new User( Helpers::cleanUpInput($login), password_hash(Helpers::cleanUpInput($password), PASSWORD_DEFAULT), (int) Helpers::getAge($age) ), new DBHelper() ); } Два вызова одного и того же WorkerFacade, отличающиеся наличием аргумента $age в одном из вызовов конструктора User, и это при том, что: PHP: public function __construct($login, $password, $age=0, $counter=null) У $age есть параметр по умолчанию. Который может быть проверен в конструкторе. Это снова спагетти. Гляди, что получается - вместо того, чтобы проверять значение параметра $age внутри конструктора объекта, которому этот параметр передается, ты проверяешь количество переданных аргументов в конструктор фабрики фасадов, который создает не пользователя, а фасад, у которого, в свою очередь, в конструкторе нужен User, у которого, в зависимости от количества аргументов, переданных в конструктор фабрики, в аргументы конструктора, в свою очередь, будет вписан или нет возраст. Это даже при чтении или на слух крайне тяжко воспринимается. А у тебя это - логика приложения. Увы, это индусский код. Очень трудно поддерживаемый. 7.1) Я так и не понял, почему просто хелперы у тебя - статика, в то время как DBHelper - это инстанцируемый объект, даже не являющийся синглтоном. Который, по логике, как раз должен быть статикой, предоставляющей слой абстракции для работы с БД в любой точке приложения, не плодя инстансы и коннекты. 8) Та же тема с проверкой на уникальность логина, что и у "предыдущего исполнителя": PHP: if(!$this->getDb()->getRecord($this->getUser())) { if($this->getUser()->getAge() < 5) { header("Location: /?register&error=fail_user_low_age"); Сначала посылаем запрос в бд, потом, если есть нет результата, проверяем возраст, потом, если все ок, посылаем еще один запрос, но уже на запись данных. Тут есть некоторая проблема в логике. Абстрагируемся: "делаем относительно дорогую операцию, чтобы разрешить сделать относительно бесплатную, чтобы потом, в случае успеха, снова относительно дорогую". В то время, как можно просто сделать логин уникальным полем в БД. Тогда алгоритм будет такой - сначала бесплатная проверка на возраст, потом относительно дорогой запрос к БД, который, может быть пройдет удачно, тогда все ок, а может быть, вернет ошибку нарушения уникальности поля, тогда говорим пользователю, что логин занят. При этом вместо гарантированного запроса и негарантированной проверки с негарантированным вторым запросом, мы получаем гарантированную проверку с негарантированным запросом. Это гораздо лучше. Фух, пока что все, что в глаза бросилось сходу, и на что хватило времени. На бОльшее его пока нет. --- Добавлено --- А еще ты выставляешь кукисы без маркера httponly, что позволяет их тырить через JS. --- Добавлено --- Ан нет, постобработкой в мозг доехало следующее: 1) Почему ты не используешь сессии? 2) Почему ты вместо сессий используешь хранение сессионных данных в кукисах, причем в просто сериализованном виде? Это тоже индуизм, увы. --- Добавлено --- Стоп. А это почему так? Зачем оно, если данные есть в БД? Я удаляю эту куку и получаю ноль на счетчике. А потом, нажимая +1 получаю 6, как будто ничего не менялось. Это снова индуизм. У тебя логика счетчика размазана по БД и кукисам, причем неаккуратно.
И на том спасибо, пока бегло прочитал, много всего. Обязательно попытаюсь вникнуть. Если сразу о вопросах: -- тут все просто это стандартно для меня и я не особо задумывался, подразумевалось, что trim - удаляет пробелы, дальше символы, которые могут быть хтмл делаем таковым и обрезаем. Изачально задумка в том, что эти символы использовать не допустимо, о чем валидатор клиентский сообщит. Но ок, к сведенью принял. -- на самом деле задача для меня была простая, абстрагировать общение с базой и вынести его в класс для удобства. Все данные которые он получает уже подразумеваются чистыми и валидными (выше было уже об этой "валидации" ). Класс user -просто тайпхинтинг в основном, отсюда эти два класса и "хелперы". Дальше фасад, который делает буквально простую вещь - скрывает ненужное и отдает интерфейс для работы, подразумевалось, что все "костыли" юзера и класса работы с базой никто не видит за ним. Ну и да "фабрика" нужна была мне для того, чтобы не добавлять логику и просто получить объект ... да на основе колличества аргументов, если честно в чем тут проблема я не понял. Тут нет ООП ради ООП, а то, что есть исключительно без чего я не могу обойтись потому, что это расширяемо и тестируемо. да звучит странно 7.1) да должен быть синглтон, но по задумке это надо выкинуть и добавить ОРМ хелперы статика просто чтобы не создавать объект, он там незачем. -- нее, логин как раз являеется уникальным полем в БД, `$this->getDb()->getRecord($this->getUser())` отправляет запрос и проверяет что текущий объект юзера ( $this->getUser() ) который был передан в воркера присутствует в базе `$this->getUser()->getAge()` в базу не ходит. --- Добавлено --- пробовал удалить ? ) Дело в том, что с этим я тоже не совсем согласен)) да я планировал это не мне очень трудно отказаться от того, к чему привык и выносить в сервер... в общем если ты очистишь куки - это предусмотренно, пользователям которые решат удалить одну куку со счетчиком могу сказать, что это их проблемы. --- Добавлено --- . ну как бы я вообще подразумеваю из js работать с клиентом. То, что тут я не писал тесты и не добавлял функционал не означает, что я готов отдать заказчику код, который вместо поддержки придется переписать
Зачем, если он и так уникален? Просто вписывай его, он либо запишется, либо вернет ошибку нарушения уникальности. Я это уже описал. И по другим пунктам много текста не просто так. Не спеши, вдумчиво прочитай, проанализируй. Давай сразу точки расставим: ты не на защите курсовой или диплома, а я не валящий препод. И тем более не манагер, которому можно объсянить, что "это не баг, это фича". Все, что я описал, это проблемы. Проблемы с логикой, с безопасностью, с архитектурой, со связностью, с использованием ресурсов сервера. Они есть. Сейчас я вижу отговорки, которые скармливают менеджерам, чтобы те приняли проект. Брось ты, не ради того все затевалось. И пишу я это не чтобы тебе самолюбие уязвить и читать отговорки. Просто исправь, или нет. Дело твое. А мое дело - обозначить проблемы.
. ну как бы я вообще подразумеваю из js работать с клиентом. То, что тут я не писал тесты и не добавлял функционал Дело в том, что то, что я далек от php и сервера не заменяет того, что в некоторых знаниях опыта у меня более 10 лет и я уверен на 101 % И разница между защитой перед менеджером или пояснением того, что это сделанно сознательно таки есть. Хотя там много моментов, которые я не учел, за что и спасибо. Но ок, пусть будет так, благодарю позже вникну, сейчас сам в дороге. по поводу того, что проблемы будут я был уверен, вопрос в том, на сколько все плохо? Можно оценку от профессионала услышать о том, как далеко это решение от кода человека способного делать это не бесплатно на этом php? К примеру чувак ты хуже первокурсника или можно браться за простые задачи - будет достаточно
А расскажи, кстати, почему эти символы не допустимы? Меня вот всегда раздражало, когда мне сайты указывают, какие я должен символы использовать а какие нет. Это похоже на форму унижения пользователя, как по мне. Если кодировка соединения с базой, кодировка, в которой работает PHP, кодировка содержимого базы и кодировка кода страницы идентичны, и кодировка эта - UTF8, то какая разница, какие из них выбрал пользователь? Какая разница, из букв у меня состоит логин/пароль или из UTF-8-шрифтовых-смайликов вперемешку с пинь-инем? Да, для mysql и php есть ряд служебных символов, которые могут быть переданы в теле запроса. И эти символы экранируются через использование prepared_statements или банального real_escape_string. Так почему недопустимо использовать уголки, спецсимволы и прочие HTML-сущности, которые усиливают пароль на порядки? Самоуверенность губит. 10 лет опыта не гарантируют ничего. Человек с 10 годами опыта должен знать, что PHP: strip_tags(htmlspecialchars(trim($value))); Является мусорным сниппетом, кочующим по интернету, и который встретить можно только у совсем новичков и учеников Попова. И который никак не защищает базу данных от инъекций. Даже если ты совсем не знаком с пхп, ты наверняка должен знать хотя бы основы работы с БД и основы безопасности оной. Так же должен знать, что нельзя использовать код не думая. Нужно как минимум читать документацию. После того, как я указал на это, я получил в ответ: А потом снова: Из чего я делаю вывод, без обид, что у тебя 10 лет опыта "делания как привык" и "как знаю", а не "как правильно", и,в данном случае, это не козырь. Как и апелляция к уверенности. Апелляция к уверенности это "все правильно сделано, мамой клянусь". В реальном мире это не работает. Тут даже скорее не уверенность, а самоуверенность, которая закрывает человеку глаза и не дает ничего, кроме оправданий неправильным поступкам. А еще она мешает развиваться. Я ведь все описал. Самое страшное - это проблемы безопасности. Ты подставляешь конечного пользователя. На эту тему надо почитать немного интернета и все будет ок. Остальное минорно и касается только проблем развития и поддержки. Но это уже "внутренние проблемы".