Обзор – Профессия PHP-программист

в случае, к примеру, с проверкой сессии лучше так:

Юзеру зачем знать залогинен он или нет ?

Использование die в данном случае (и в 99% других случаев) не оправдано, если хочешь сказать юзеру что что-то пошло не так то лучше просто

if(!isset($_SESSION['loggedin'])) {
	header('Location: /?page=error');
// а на "/?page=error" может быть сказано
/* "если вы на этой странице, то либо глюки у нас, либо у вас, проверьте ваши глюки, а мы проверим наши */
	exit;
}

Ошибки пишутся в логи, а юзеру совершенно плевать залогинен он или мускул в дауне, или файлы слетели, это не его проблема, его касается то попадёт он на нужную страницу или нет. (а если он и вовсе "мега-кул-хацкер" и сам незалогиневшись зашёл на "/admin/index.php?page=admin" чтоб попробовать кого-то взломать, то и тем более подробности ему не нужны, либо он их и так знает, либо ему лучше их не знать)

Я тоже по молодости писал подобное, сейчас даже толком не проверяю соединение к базе перед отправкой запроса, просто проверяю что пришло и если пришло нормально то вывожу, а если будут глюки я увижу в логах их причины, а юзеру знать подробности вовсе незачем, он просто увидит страничку о том что что-то не так, и что надо попробовать позже...

Сообщение изменено: Vladson (18 ноября 2008 - 23:40 )

Юзеру зачем знать залогинен он или нет ?

Ну вот просто предположим, зашел юзер на сайт, сидит, сидит, ушел чай делать. Возращается - сессия уже умерла, а он про это не знает. Надо же узнать?

ЗЫ про особенность die() писать в логи я и не знал 0_о
Ну, можно заменить на

echo "что-то"; return 0;

Разницы никакой...

Сообщение изменено: windburn (19 ноября 2008 - 13:38 )

расстреляйте меня, но я буду спорить до пены у рта, что конструкция

die "Ahtunge" unless authorized?

гораздо удобнее, чем

if(!isset($_SESSION['loggedin'])){ die('Not logged in'); }

Тест Тьюринга отдыхает)

про особенность die() писать в логи я и не знал

Её и нет, потому что пишутся ошибки сервера, а не то что юзер ушёл пить чай. Эти ошибки мне знать также не нужно как юзеру знать о том в какой строке скрипта пропущена запятая или скобка.

расстреляйте меня, но я буду спорить до пены у рта

Вот и я не буду спорить, это дело вкуса и привычки, а существенной разницы совершенно никакой нет.

Сообщение изменено: Vladson (19 ноября 2008 - 21:02 )

В любом случае стиль написания и вообще сам код зависят от конкретной ситуации и конкретных нужд. Так что глупо спорить о том, что это никому не нужно и практической ценности не несет, смысла нет

стиль написания и вообще сам код зависят от конкретной ситуации и конкретных нужд

Есть красивый код и некрасивый, правильный и неправильный. красивый код может быть правильным в зависимости от ситуации, некрасивый может быть правильным в зависимости от ситуации, неправильный правильным быть не может в любом случае красивый он или некрасивый...

Есть ... правильный и неправильный...

Любой работающий код - правильный!!!

Поддерживаю предыдущего оратора)
К тому же идеального варианта написания кода для определенной задачи не существует. В этом и заключается индивидуальность)

Любой работающий код - правильный!!!

Ну ну.. допустим один программист написал код работающий за O(2^n) второй написал код работающий за O(n) оба кода делают одно и тоже, хотите сказать оба варианта правильные?

Любой работающий код - правильный!!!

Даже тут в котором встроен троян ?

Даже тут в котором встроен троян ?

Код же делает то, что хотел программист? Делает. Значится, правильный

А к чему этот бессмысленный спор? Всё равно каждый останется при своём мнении.

Естественно, код должен отвечать неким базовым нормам: безопасности, стиля кодирования. Кто "в теме", тот поймёт о чём идёт речь. Если мы говорим о PHP, то лет 5 назад OOP-подход не был так популярен, как сейчас и качество PHP кода за последние годы очень сильно выросло, свидетельство тому - появление с выходом PHP5 таких ОО фреймворков, как Zend и Symfony. И любое следование принципам PHP4 (PHP5 strict) сегодня ИМХО является безрассудным

Код же делает то, что хотел программист?

Нет, программист не хотел, просто вот написал скрипт, а оказалось что там бэкдор. (без ведома программиста он там оказался)

Естественно, код должен отвечать неким базовым нормам: безопасности, стиля кодирования

Вот и я о том-же, а некоторые товарищи утверждают что сие не так, и что коду достаточно быть "работающим"

любое следование принципам PHP4

Скрипты бывают разные, для сайта интернет-магазина (не навороченного, простенького очень типа таких как у нас в эстонии) наоборот чем проще код (точнее чем его меньше) тем проще следить за безопасностью, быстрее а стало быть дешевле в написании (3-4 скрипта по 3-5кб не считая шаблонов) из недостатков только неудобная модернизируемость (и то это ещё зависит от того как написать) но в 99% сайты такого уровня делаются один раз и на годы...

Сообщение изменено: Vladson (21 ноября 2008 - 02:20 )

Естественно, код должен отвечать неким базовым нормам: безопасности, стиля кодирования. Кто "в теме", тот поймёт о чём идёт речь. Если мы говорим о PHP, то лет 5 назад OOP-подход не был так популярен, как сейчас и качество PHP кода за последние годы очень сильно выросло, свидетельство тому - появление с выходом PHP5 таких ОО фреймворков, как Zend и Symfony. И любое следование принципам PHP4 (PHP5 strict) сегодня ИМХО является безрассудным

Правильно излагаешь, я с тобой совершенно согласен.
P.S. Если честно, то Zend мне не понравился, слишком там уж запутано всё с директориями и их слишком много, а вот отдельные модули Zend достойная замена уже устаревшему PEAR.

Скрипты бывают разные, для сайта интернет-магазина (не навороченного, простенького очень типа таких как у нас в эстонии) наоборот чем проще код (точнее чем его меньше) тем проще следить за безопасностью, быстрее а стало быть дешевле в написании (3-4 скрипта по 3-5кб не считая шаблонов) из недостатков только неудобная модернизируемость (и то это ещё зависит от того как написать)

Я говорю о базовых вещах, конечно не надо бить по мухе из пушки.

По опыту скажу, что маленькие скрипты в коммерческом секторе (магазины) обречены, что может стоить фирме больших денег: поддержка старого кода будет занимать много времени, используемые в старом коде принципы сегодня уже не актуальны и некоторые из них могут быть полностью опровергнуты! Если фирма решит развивать свой магазин - придётся всё переписывать. Т.е. подобные скрипты имеют а) срок годности б) высшую точку развития, после кторой будет дешевле начать всё заново, чем поддерживать древний код. Рано или поздно PHP4 уйдёт, не надо пытаться его поддерживать, т.к. это уже прошлое. Ради нескольких сайтов сегодня и в блайшее время мы жертвуем целым будущим.

В эстонии 90% шопов на старом eCommerce... уже тошнит от них

но в 99% сайты такого уровня делаются один раз и на годы...

Именно по-этому тут и говорят, что главное чтобы код работал и отвечал базовым принципам. Но я всё равно выступаю против таких доморощенных скриптов, ибо подобную работу надо ставить на конвеер и использовать как можно больше готовых наработок.

P.S. Vladson, я не пытаюсь с тобой спорить, просто поддерживаю дискуссию. Ситуации бывают разные, если очень попросят, я тоже могу написать простой скрипт, иногда задача стоит: надо написать простой скрипт и вставить его на какой-то сайт. Сверху я пытаюсь мыслить более абстрактно.

Setor, я считаю, в екоммерсе избавляясь от накладных затрат на торговое помещение и обслуживающий персонал, стоит инвестировать сэкономленные песо в разработку и поддержку онлайн-шопа, если на нем нет развития: не добавляются новые функции, не обновляется ассортимент, не устраняются ошибки - болтаться такому бизу в хвосте или сдохнуть. В этом плане, подход окса мне очень импонирует.

Сообщение изменено: zedirtybastard (21 ноября 2008 - 13:18 )

Setor, я считаю, в екоммерсе избавляясь от накладных затрат на торговое помещение и обслуживающий персонал, стоит инвестировать сэкономленные песо в разработку и поддержку онлайн-шопа, если на нем нет развития: не добавляются новые функции, не обновляется ассортимент, не устраняются ошибки - болтаться такому бизу в хвосте или сдохнуть. В этом плане, подход окса мне очень импонирует.

Да, живой тому пример всякие atf, aruvitkeskus'ы и т.п. как они только живут со своими ценами. В половине магазов заказ надо отсылать на мыло или искать менеджера в аське - где это видано в XI-век... У них явно гнилые сайты, чуть дунешь и развалятся. Ребята даже не подозревают что такое SQL-injection.

Вырвалось...

Я всегда очень трепетно относился к е-шопу enter'а. Меня поражало качество сайта и скорость, с которой разработчики внедряли новый функционал/изменяли старый. Иногда мне были непонятны их нововведения, т.к. я не мог понять, зачем они их делали и почему именно так... Ведь некоторые вещи могли оказаться сложными для рядового покупателя.

Вчера я случайно сделал для себя открытие, что шоп крутится на быстро набирающим популярность опенсурсном eCommerce движке Magento!

Хотел поддержать разработчиков из laborint, но теперь я немножко разочарован и отдаю все свои похвалы разработчикам Magento, а laborint'у: кто вас учил юзабилити? кто будет фигачить круги у вас на сайте, чтобы увидеть портфолио... ужасное решение (кто не понял http://www.laborint.com/ )

По опыту скажу, что маленькие скрипты в коммерческом секторе (магазины) обречены, что может стоить фирме больших денег: поддержка старого кода будет занимать много времени, используемые в старом коде принципы сегодня уже не актуальны и некоторые из них могут быть полностью опровергнуты!

Поддержка (как таковая) того о чём я говорю не нужна вообще, поставил и забыл на годы, минус только в том что доработка (добавление функций) скорее всего выйдет дороже (и дольше) раз в 5-10 чем аналогичная работа на "качественном" движке.

если на нем нет развития: не добавляются новые функции, не обновляется ассортимент, не устраняются ошибки - болтаться такому бизу в хвосте или сдохнуть

Увы 99% е-шопов в эстонии именно такие

Сообщение изменено: Vladson (22 ноября 2008 - 14:55 )

Поддержка (как таковая) того о чём я говорю не нужна вообще, поставил и забыл на годы, минус только в том что доработка (добавление функций) скорее всего выйдет дороже (и дольше) раз в 5-10 чем аналогичная работа на "качественном" движке.

В этом даже нет ничего удивительного. С чего обычно всё начинается:

1) Заказчик имеет либо оффлайн точку, либо просто решил заняться онлайн-продажами
2) Заказчик находит (или не находит) в интернете сайты конкурентов
3) Заказчик начинает узнавать, во что выльется ему открытие шопа

Теперь встаёт вопрос, сколько денег он готов вложить в свой магазин. Сначала все мечтают об аналоге ozon'а, но когда слышат стоимость разработки - соглашаются на osCommerce. Причём, с такой мыслью: если продажи пойдут, то будем расширяться (напишем свой озон). Открывают говношоп, в котором продаж конечно нет, либо совсем мало и на магазин забивают.

Возможен второй вариант развития событий: девелопер всё же уговаривает заказчика писать свой продукт и через пол года получается костыль, который ещё хуже, чем osCommerce. Бабла засажено море, что делать - продаж нет, девелопер пропал, ни кто лезть в движок не хочет.

Возможен третий вариант: есть бюджет, есть честный девелопер (команда разработчиков), на базе современного, качественного, развивающегося готового (возможно бесплатного) ПО создаётся сайт с уникальным дизайном (дизайн 5-10к крон), установка и настройка шопа (10-20к). За те же деньги и втрое большее время был бы написан костыль из 2го варианта. Внедрение должно занять не более 3х месяцев (1-2 в идеале). Пол дела сделано, потенциальные покупатели по крайней мере не разбегутся впервые попав на сайт.

Сайт готов. Теперь надо вкладываться в раскрутку... Потребуется хороший SEO'шник. Будет дорого, но ничего не поделаешь, сайт сам по себе не раскрутится (либо на раскрутку уйдёт несколько лет). Известны случаи покупки рекламы на говнодельфях за огромные деньги и 0-я отдача. К раскрутке нужно подходить с умом, иначе толку от неё не будет.

Без инвистиций далеко не уедешь, а с плохой командой вообще ни куда не уедешь, только в яму

Ну, забыл и поставил на годы - звучит слишком смело, в конце концов это же не вечный двигатель, чтобы приносить деньги без вмешательства человека...
Если шоп не меняется уже много месяцев, не обновляется, нулевой суппорт и так далее - даже на ozon уже давно бы забили все клиенты

Ну, забыл и поставил на годы - звучит слишком смело, в конце концов это же не вечный двигатель, чтобы приносить деньги без вмешательства человека...
Если шоп не меняется уже много месяцев, не обновляется, нулевой суппорт и так далее - даже на ozon уже давно бы забили все клиенты

Мы не говорим о саппорте, мы говорим о магазине. Большинство магазинов вполне успешно торгуют уже ни один год на каких-то говнодвижках, они не вкладываются в разработку и поддержку (речь идёт о поддержке кода, а не клиентов), просто снимают прибыль (если она есть).

Обычно такие шопы живут за счёт низких цен и просто не могут позволить себе с минимальной маржой развиваться. Т.е. рано или поздно конкуренты их задушат. Возможно на это уйдут годы, но магазин с такой политикой обречён.

Конечно, всегда найдутся покупатели, которые готовы убить за каждую копейку, им хоть прайс в csv формате дай, лишь бы цена была ниже всех - есть такие кадры

Сообщение изменено: Setor (22 ноября 2008 - 16:07 )

Хм... я такие не встречал, однако. Месяц-два, но вряд ли больше. Вообще, в инет-шопах не последнюю роль играет доверие клиента к продавцу, а о каком доверии может идти речь, если сайт крутится на стандартном бесплатном движке, обновлялся в последний раз еще до всемирного потопа с ковчегом, и все такое...

а о каком доверии может идти речь, если сайт крутится на стандартном бесплатном движке

А какое дело покупателю до того, на каком движке крутится магазин? Клиенту важна внешность сайта, имя (доверие) продавца и удобство. Остальное полный барабан. Ты когда в продуктовый магазин приходишь, ты спрашиваешь у них имя директора, кол-во складов, логистические подробности поставки товара и формирования цен, состав материала подставок под продукты, проект постройки здания магазина и т.д. Покупателю это всё неважно, главное ассортимент, его качество, уют и обслуживание. Тут тоже самое, для покупателя важна внешняя часть дела. Да и бесплатные движки - это не обязательно полное Г...

А какое дело покупателю до того, на каком движке крутится магазин? Клиенту важна внешность сайта, имя (доверие) продавца и удобство. Остальное полный барабан. Ты когда в продуктовый магазин приходишь, ты спрашиваешь у них имя директора, кол-во складов, логистические подробности поставки товара и формирования цен, состав материала подставок под продукты, проект постройки здания магазина и т.д. Покупателю это всё неважно, главное ассортимент, его качество, уют и обслуживание. Тут тоже самое, для покупателя важна внешняя часть дела. Да и бесплатные движки - это не обязательно полное Г...

В магазине клиенту важно:
1) Найти интересующий его товар как можно быстрее (например, через поиск)
2) Получить исчерпывающую информацию о найденном товаре (описание, фото)
3) Оформить заказ
4) Оплатить заказ (через удобный клиенту банк (pangalink)/креду/лизинг)
5) Получить заказ вовремя (в кротчайшие сроки)
6) Получить в кратчайшие сроки саппорт (гарантийные случаи и телефонный саппорт)

Если хоть один из этих пунктов будет хромать, магазин как таковой тоже будет хромать.

Возьмём пример из жизни: я постоянно езжу за покупками в Prisma, но у меня недалеко от дома есть сястик и тмаркет, а рядом с призмой стоит Rimi. Почему я выбрал призму?
1) Я знаю что где в ней лежит (в рими я просто теряюсь, в других магазинах выбор никакой)
2) Если я не уверен в цене, я могу её узнать через спец. терминал
3) В кассах обычно не много народу + у меня есть сястукарт, которая даёт какой-то бонус (небольшой, но приятный). В Rimi в кассах много народу, в сястике вообще работает 1 касса и километровая очередь из пожилых людей, причём, кто-то ругается что так долго, а кто-то дышит сзади перегаром. В тмаркете тоже толкучка.
4) С оплатой никаких проблем в призме не возникало, а вот в рими, хоть я и бываю редко, но 1 раз терминалы не принимали карты, все ломанулись в банкоматы. Несколько раз в рими мне пробивали товар по неправильной цене. В тмаркетах и сястумаркетах очень долго возятся и пересчитывают мелочь (центы), а пару раз в тмаркете и сястике мне отказались продать товар, т.к. он не пробивался в кассе.
5) В призме самые оптимальные очереди и длинные конвеерные ленты на кассах
6) В случае вопросов всегда можно подойти в инфо-пункт и спокойно обсудить проблему (в сястике однажы бабуля не разглядела содержимое чека и минут 10 ей 3 продавщицы ручкой!! обводили цифры в чеке, перевзвешивали её лук, яблоки и т.д. работала одна касса.)

Сообщение изменено: Setor (22 ноября 2008 - 17:36 )

если сайт крутится на стандартном бесплатном движке

Не все клиенты е-магазинов е-специалисты !!! (более того таких настолько мизерный процент что им смело можно пренебречь)

Клиенту важна внешность сайта, имя (доверие) продавца и удобство.

Подписываюсь под каждым словом. Добавлю только что цена имеет также не малый вес.

То на каком движке двиг важно для самого магазина (сколько денег они вложат до того как он станет работать, сколько будут вкладывать дальше чтоб он работал, и сколько будет стоить его доработка при необходимости, хотя последним чаще всего пренебрегают)

Усиленно изучаю PHP-программирование. Специалистов в данной области как мне показалось с руками отрывают.
Собственно, интересуют следующие вопрос:
- Минимальные требования для работы, что надо уметь?
- Какие критерии оценки специалистов?
- Кто – где работал – работает – в чем суть вашей работы, как PHP-программиста?

,
Уважаемый Верон, позвольте немного поразглагольствовать о PHP:
Плюсы PHP:
1) Легкость изучения - этот язык сможет освоить даже полный дебил
2) Просто огромная куча написанного кода
3) Несложно найти работу, халтурку (правда низкооплачиваемую и грязную)

Минусы(идут из плюсов):
1) Нестрогая типизация, что ведет к писанине в макаронном стиле. Есть нормальные прогеры на ПХП, где-то есть даже красивй код на ПХП, но
2) 95% всего существующего кода на PHP, извиняюсь, есть полное г***о. Люди учатся програмированию изучая чужой код, но похоже, что это не относится к Пехапе программистам - каждый норовит изобрести свои грабли.

PHP программисты - это низшая каста среди IT. На ЛОРе есть даже термин специальный, который отражает суть 99% всех людей, пишущих на PHP - Пых-Пых-Быдло-Кодер. 15 тысяч крон в месяц при 170 часах работы - это фактический потолок зарплат для PHP девелопера в Эстонии. Я знаю нескольких людей, которые зарабатывают по 25К в месяц , но рабатают они по 10 часов в день без выходных (фактически 250-300 часов в месяц). Почему нет ни одной банковской системы написанной на PHP? PHP - это удел хомяков и маленьких шопов. Все крупные проекты связаане с финансами пишутся на JAVA или дот нете.

Вот мой вам совет - сожгите все свои книги по ПеХеПе, купите книги по
1) JAVA
2) Рефакторингу, шаблонам проектирования
3) UML
4) JBI, ESB (Если уж хорошо попрет)
5) Oracle
и изучите все это. Через годик или как пойдет постарайтесь устроится интерном в какую-нибудь крупную фирму за минималку или даже бесплатно (Playtech, HireRight, WebMedia на худой конец). И через 2-3 года вы сможете на интервью у потенциального работодателя просить мимнимум 20 к в месяц.

Не надо быть быдло-кодером, а надо стремиться туда, где тусуются гуру. В PHP одни неудачники.

Успехов

Rhydan, +1, полностью согласен.

Сообщение изменено: Slаm (27 ноября 2008 - 01:48 )

После фраз

Есть нормальные прогеры на ПХП

В PHP одни неудачники.

не хочется особо комментировать (человек который пишет одно, думает другое, а потом забывая что написал выше пишет уже третье не вызывает у меня особого доверия)

Но местами я согласен, а конкретно с плюсами и минусами РНР, и в правду "куча написанного кода" и в правду "95% всего кода на PHP, полное г***о" (по крайней мере в OpenSource, куда не глянь везде дырявые поделки школьников)

Вот только не согласен я с тем что освоить РНР может даже дибил.

Нет, синтаксис освоить конечно может, это без вопросов, но вот только знание синтаксиса и умение программировать это немного разные вещи.