о чём и я говорю. для маководов - очень тонкая грань между платно за хорошее качество и платно за то, что ничего толком не стоит но предоставляют в красивой упаковке.
когда-то я работал над проектом приложения "удалённого рабочего стола". компания citrix как на то время так вродебы и сейчас владеет лицензией на самый оптимальны (быстрый и не ресурсоёмкий) протокол работы удалённого рабочего стола. так вот, изучая citrix я познакомился с одним опытным в этой сфере человеком, который рассказал следующую байку - "компания мелкософт сама создала citrix, и все эти годы спонсировало её. для чего - возможно для уменьшения монополии, ведь очень выгодно создать компанию-противника, которая фактически есть филиалом". также, вродебы citrix и первое NT ядро мелкомягким сделало....
поэтому вполне вероятно, что девушку на этих страницах размещал один и тот же дизайнер...
по поводу интерфейса:
1) на первой странице должно просто быть написано о сервисе. не надо стоко текста как на "О сервисе". но и так мало как сейчас на титульной - тоже плохо.
2) смысл закладок (меню вверху) понятен только после перехода по ним...
3) демонстрация графика и скриншот расчитанной стоимости выделяется из общего дизайна. какбуд-то движок графика не писали сами под дизайн а брали простейший бесплатный готовый...
4) даже на демо скриншоте нет простоты и интуитивности. в результате нет желание регистрироваться и смотреть дальше. может, потому что я не экспедитор... но вот для экспедиторов - накидайте в пример больше строк. чтобы было мнение что у вас там уже миллион компаний и служб)
Но это токо моё мнение)
как по мне, подобный сервис нужно предоставлять в связке с информацией по грузам/транспорту. чтобы всё было под рукой. Заказчикам восновном нужно доставить груз за определённую сумму, а дальше - экспедиторы занимаются впихиванием груза перевозчику, а перевозчик - как на аукционе: "поеду"/"не поеду".
также, ИМХО тяжёлый и непонятный с первого взгляда интерфейс системы(
они предоставляют вам простейший инструмент, набор аксиом, работа которых много раз обсуждалась и известно, что проще делать некуда... вы его усложняете своей логикой. а что будет, если вы усложните уже свою логику? или быть может тогда не стоит использовать ПХП а разрабатывать своё? ведь оно то точно лучше всех существующих будет))
я привёл тут пример для опыта, чтобы проверить быстродействие пхп с обычным кодом и с классами, при похожем конечном результате в использовании...
Обращения к диску за инклуами можно отбить пхп-кэшами. например, АПР...
разница есть. пхп тратит много времени на разбор свойств класса и его методов. например, возьмите прототипы таблиц какой либо БД. В одном методе создайте прототипы для 100 таблиц в виде ассоциированных массивов (название колонки->значение). а в другом - каждой таблице создайте прототив объекта (класс с переменными для колонок и геттерами/сеттерами). тоже 100.
затем просто заинклудьте 100 файлов с массивами и посмотрите на время. а потом тоже самое с классами - отличие явное( хоть ООП и гибче(
у нас в большом проекте сначала никто не задумывался использовать что-то другое кроме стандартной сессии... но навсяк случай сделали обёртку. так вот, одной сессий пользовались все модули системы и как фронтенд так и бекэнд, и впоследствии за пять минут (в обёртке перед сохранением в сессию изменялся ключ - добавлялся префикс модуля) получилось разграничить все модули и подчистить лишние, неиспользуемые данные...
Попробую не согласиться... Это только моё мнение, поэтому как уже оцените - ваша воля. Каждый раз, когда я раньше думал "мая лесапета будет круче" - садился и писал. Было большое чувство удовлетворённости по окончанию писюльки. Со временем обленился вкрай... И начала посещать мысль - "а нет ли готовых решений?". Ведь не даром разработчики во всём мире используют готовые библиотеки и компоненты. Например посмотрите на обилие контролов для ASP.Net и на их цены. цены кусаются а библиотек - валом....
Но что-то я отклонился. Так вот: вы только подумайте - "сколько у ПХП разработчиков (в частности компания Зенд) уже опыта в создании этого движка?" Неужели они за столь длительное время не закрыли дыры в таком частоиспользуемом элементе как Сессии? И неужели они не повышают его быстродействие?
Повторюсь, только моё мнение, что базовой функциональности сессий - с головой хватает для простых сайтов. А для сложных можно использовать как Мемкэш или БД, как уже упоминалось. Но ведь это тоже некоторым образом ограничевает разработчика в определённой области. Например, будете использовать только БД или только файлы и тд.
А почему бы не выбрать что-то среднее? Например создать "обёртку" для стандартной сессии? Написание обёртки и её отладка займёт всего пару часов. Может даже и час :) Но зато эта обёртка будет оценивать ключ для сохранение в сессию и, в зависимости от логики, "нужные" элементы пихать в базу, а не нужные хранить например в памяти... Даже не добираясь до файла. Ведь не все используют на прямую функции работы с МуСКуЛом? :)
А используя класс-обёртку как для доступа к бызе так и для сессии, а также и для других утилит - проект становится более объектно-ориентированным, а также гибким и легко-расширяемым.
session_set_save_handler - хорош, но это немного скрывает ООП, которое и так тяжело проявить в ПХП.
Спасибо, что дочитали эти мысли до данной строки)
поэтому вполне вероятно, что девушку на этих страницах размещал один и тот же дизайнер...
1) на первой странице должно просто быть написано о сервисе. не надо стоко текста как на "О сервисе". но и так мало как сейчас на титульной - тоже плохо.
2) смысл закладок (меню вверху) понятен только после перехода по ним...
3) демонстрация графика и скриншот расчитанной стоимости выделяется из общего дизайна. какбуд-то движок графика не писали сами под дизайн а брали простейший бесплатный готовый...
4) даже на демо скриншоте нет простоты и интуитивности. в результате нет желание регистрироваться и смотреть дальше. может, потому что я не экспедитор... но вот для экспедиторов - накидайте в пример больше строк. чтобы было мнение что у вас там уже миллион компаний и служб)
Но это токо моё мнение)
также, ИМХО тяжёлый и непонятный с первого взгляда интерфейс системы(
Обращения к диску за инклуами можно отбить пхп-кэшами. например, АПР...
затем просто заинклудьте 100 файлов с массивами и посмотрите на время. а потом тоже самое с классами - отличие явное( хоть ООП и гибче(
Но что-то я отклонился. Так вот: вы только подумайте - "сколько у ПХП разработчиков (в частности компания Зенд) уже опыта в создании этого движка?" Неужели они за столь длительное время не закрыли дыры в таком частоиспользуемом элементе как Сессии? И неужели они не повышают его быстродействие?
Повторюсь, только моё мнение, что базовой функциональности сессий - с головой хватает для простых сайтов. А для сложных можно использовать как Мемкэш или БД, как уже упоминалось. Но ведь это тоже некоторым образом ограничевает разработчика в определённой области. Например, будете использовать только БД или только файлы и тд.
А почему бы не выбрать что-то среднее? Например создать "обёртку" для стандартной сессии? Написание обёртки и её отладка займёт всего пару часов. Может даже и час :) Но зато эта обёртка будет оценивать ключ для сохранение в сессию и, в зависимости от логики, "нужные" элементы пихать в базу, а не нужные хранить например в памяти... Даже не добираясь до файла. Ведь не все используют на прямую функции работы с МуСКуЛом? :)
А используя класс-обёртку как для доступа к бызе так и для сессии, а также и для других утилит - проект становится более объектно-ориентированным, а также гибким и легко-расширяемым.
session_set_save_handler - хорош, но это немного скрывает ООП, которое и так тяжело проявить в ПХП.
Спасибо, что дочитали эти мысли до данной строки)