RokkoJ: Реально ИМ подразумевает как минимум оформление заказа, а в идеале сразу и оплату.
И для этого тоже не обязательно иметь движок ИМа. И корзина тоже может быть лишняя.
Простой пример - продажа яхты. Ассортимет - 30 шт.
Функции формирования товара клиетом - цвет и такелаж.
Оформил, оплатил. На этом весь функционал ИМа вроде бы заканчивается. Но грамотный разраб понимает, что те же выборы и фильтры это уже что-то. Равно как и бекэнд.
Ида. ИМ - это всего лишь Интернет Магазин. Площадка для продаж. Если с её помощью есть возможность продавать (покупатель может выбрать товар и сделать заказ) - это ИМ.
livetv: Это противоречит Вашему утверждению, что он не должен понимать...
Никак не противоречит!
В ТЗ не нужно указывать разрабам как решать. Нужно писать что нужно получить. Это пишется простым, "бытовым" языком. В некоторых случаях - терминология продавца. Но никак не разраба.
---------- Добавлено 05.12.2015 в 14:35 ----------
livetv: Это будет херня на постном масле.
Такие высказывания приличные люди обосновывают.
Но это не о тебе, правда? Ты же даже по ссылке не прошел.
И да как раз выше уже ответил RokkoJ. Как раз на это же.
ghost28: Не соглашусь. Разраб не обязан понимать в удобстве пользования.
Я и не говорил, что придумать удобство - задача разраба. Задача разраба - реализовать удобства, согласно ТЗ. (на практике же - подобрать "типовой проект", согласно ТЗ и скорректировать под нюансы/хотелки)
АПД. Но нормальный разраб ИМа всё-таки должен понимать задачи заказчика, а значит и удобства :)
RokkoJ: Да не ИМ это, а просто витрина. Реально ИМ подразумевает как минимум оформление заказа,
Половина заказчиков с тобой не согласна :)
80% из оставшейся половины не нужно 50% того, что несут на борту универсальные ИМ движки. И хорошо, если это не мешает.
Но вот опя же из практики - даже текст письма покупателю ИМа мало кто проверит. А есть ещё и более "тонкие материи", о которых владелиц ИМ даже не подозревает. А их нужно настроить, и сделать это может только владелец. А разрабы или не хотят ему об этом говорить или даже не знают об этом. Но тут опять же не столько вина разрабов, сколько ограниченность бюджета заказчика.
Присущ: Вот только это не ИМ будет, а тест попробовать приглядеться посмотреть, потом все равно придется менять подход, если есть желание не иметь ИМ для того, чтоб его показывать на визитке, а иметь чтоб он реально работал и приносил прибыль.
Вот тут есть нюанс. И достаточно серьёзный в плане отношения к понятию "ИМ".
Как далеко не всем офлан-продавцам нужны огромные торговые площади, развитая логистика, склады и собственные банки, так большинсву онлан-продавцам не нужно ПО, все это дело разруливающее.
И он даже может приносить дохода больше, чем самый навороченый скрипт ИМа со штатом менеджеров и уборщиц. (продать одну яхту в год или продать 100500 канцтоваров на ту же сумму в от же год - разница в трудозатратах и содержанию биза огромна)
Присущ: Еще кнопочка купить. Когда смотришь аудиты, почти всего пишут кнопку надо сделать больше и ярче доказывая, что от ее размеров зависят продажи.
Ой, да чего только не доказывают заказчики. Особенно почитав СЕОшников и др аудиторов :)
livetv: Большинство заказчиков не то что невменяемы, а просто не шарять в интернете/разработке.
я тебе открою страшную тайну - они и не должны это знать. Не их это дело. Они должны уметь продавать. А ИМ - всего лишь один из инструментов, призванных помочь им в этом. Вот насколько удобен этот инструмен и как будет справляться с задачами - это уже задачи и даже проблема разрабов. А разрабы в большинстве своём (как видно по многочисленным топикам на сёрче) не понимают
livetv: чем, собственно, ИМ отличается от обычного сайта
, кроме как наличием корзины. :)
Вот тут-то заказчик и попадает. Но тут он на 90% виноват сам. Какое ТЗ и бюджет - такой и результат.
Впрочем, как показывает всё та же практика, подавляющее число заказчиков думает - "вот ща заимею ИМ и тут же обогащусь". Так что в среднем по больнице то на то и выходит :)
MP-SEO: Да, но у этих двух документов фактически разный адрес.
Сегодня разный, завтра ЧПУ захочется сменить - и?
Ещё раз - если бы движок не позволял гибко менять правило ЧПУ, то да, это однозначно разные урлы. Но раз позволяет (да ещё и изменять иерархию контента) - это такая защита от совпадений разных страниц по одинаковому урлу.
MP-SEO: Пока есть задача
Это "задача" - следствие СЕО-заблуждений :). Я бы даже сказал неграмотности. Нужно просто научится смотреть выдачу и тогда не будет ни волнений по пустякам ни поисков костыльных "решений".
Да, насчёт этого:
Реально ИМ подразумевает как минимум оформление заказа, а в идеале сразу и оплату.
И для этого тоже не обязательно иметь движок ИМа. И корзина тоже может быть лишняя.
Простой пример - продажа яхты. Ассортимет - 30 шт.
Функции формирования товара клиетом - цвет и такелаж.
Оформил, оплатил. На этом весь функционал ИМа вроде бы заканчивается. Но грамотный разраб понимает, что те же выборы и фильтры это уже что-то. Равно как и бекэнд.
Ида. ИМ - это всего лишь Интернет Магазин. Площадка для продаж. Если с её помощью есть возможность продавать (покупатель может выбрать товар и сделать заказ) - это ИМ.
Это противоречит Вашему утверждению, что он не должен понимать...
Никак не противоречит!
В ТЗ не нужно указывать разрабам как решать. Нужно писать что нужно получить. Это пишется простым, "бытовым" языком. В некоторых случаях - терминология продавца. Но никак не разраба.
---------- Добавлено 05.12.2015 в 14:35 ----------
Это будет херня на постном масле.
Такие высказывания приличные люди обосновывают.
Но это не о тебе, правда? Ты же даже по ссылке не прошел.
И да как раз выше уже ответил RokkoJ. Как раз на это же.
Не соглашусь. Разраб не обязан понимать в удобстве пользования.
Я и не говорил, что придумать удобство - задача разраба. Задача разраба - реализовать удобства, согласно ТЗ. (на практике же - подобрать "типовой проект", согласно ТЗ и скорректировать под нюансы/хотелки)
АПД. Но нормальный разраб ИМа всё-таки должен понимать задачи заказчика, а значит и удобства :)
Да не ИМ это, а просто витрина. Реально ИМ подразумевает как минимум оформление заказа,
Половина заказчиков с тобой не согласна :)
80% из оставшейся половины не нужно 50% того, что несут на борту универсальные ИМ движки. И хорошо, если это не мешает.
Но вот опя же из практики - даже текст письма покупателю ИМа мало кто проверит. А есть ещё и более "тонкие материи", о которых владелиц ИМ даже не подозревает. А их нужно настроить, и сделать это может только владелец. А разрабы или не хотят ему об этом говорить или даже не знают об этом. Но тут опять же не столько вина разрабов, сколько ограниченность бюджета заказчика.
Все эти нюансы на уровне для чего.
Абсолютно верно! Хотя ТЗ никто не отменяет ;).
Но я о том, я что у большинства разборов на слово "ИМ" тут же моментальная - _единственный_двидок_который_я_знаю_, а ещё лучше - самописЬ:)
Вот только это не ИМ будет, а тест попробовать приглядеться посмотреть, потом все равно придется менять подход, если есть желание не иметь ИМ для того, чтоб его показывать на визитке, а иметь чтоб он реально работал и приносил прибыль.
Вот тут есть нюанс. И достаточно серьёзный в плане отношения к понятию "ИМ".
Как далеко не всем офлан-продавцам нужны огромные торговые площади, развитая логистика, склады и собственные банки, так большинсву онлан-продавцам не нужно ПО, все это дело разруливающее.
ИМ может быть совсем простой, и даже без корзины, но это всё равно будет ИМ.
И он даже может приносить дохода больше, чем самый навороченый скрипт ИМа со штатом менеджеров и уборщиц. (продать одну яхту в год или продать 100500 канцтоваров на ту же сумму в от же год - разница в трудозатратах и содержанию биза огромна)
Еще кнопочка купить. Когда смотришь аудиты, почти всего пишут кнопку надо сделать больше и ярче доказывая, что от ее размеров зависят продажи.
Ой, да чего только не доказывают заказчики. Особенно почитав СЕОшников и др аудиторов :)
Идею с файлами не разделяю, зачем писать велосипед обработки файлов, если можно использовать готовые решения
Файлы - не готовые решения?
А как, интересно, посмотреть логи почему БД рухнула или тупо при не хватке памяти/потоков на запись 🍿
Большинство заказчиков не то что невменяемы, а просто не шарять в интернете/разработке.
я тебе открою страшную тайну - они и не должны это знать. Не их это дело. Они должны уметь продавать. А ИМ - всего лишь один из инструментов, призванных помочь им в этом. Вот насколько удобен этот инструмен и как будет справляться с задачами - это уже задачи и даже проблема разрабов. А разрабы в большинстве своём (как видно по многочисленным топикам на сёрче) не понимают
чем, собственно, ИМ отличается от обычного сайта
, кроме как наличием корзины. :)
Вот тут-то заказчик и попадает. Но тут он на 90% виноват сам. Какое ТЗ и бюджет - такой и результат.
Впрочем, как показывает всё та же практика, подавляющее число заказчиков думает - "вот ща заимею ИМ и тут же обогащусь". Так что в среднем по больнице то на то и выходит :)
А как избежать потери данных в текстовом файле, при переносе
Использовать нормальные винты и универсальную кодировку.
Можно периодически архивировать и пересылать на др сервер/мыло.
И если к примеру я ввожу
dkjln4589y3hksjsdf.domen.ru , то откроется рандомно любой сайт с моего сервера, который находиться на данном ip
Не любой, а дефолтный.
Как это фигню убрать?
Обратиться к хостеру, что бы отключил вилкард-поддомены.
Да, но у этих двух документов фактически разный адрес.
Сегодня разный, завтра ЧПУ захочется сменить - и?
Ещё раз - если бы движок не позволял гибко менять правило ЧПУ, то да, это однозначно разные урлы. Но раз позволяет (да ещё и изменять иерархию контента) - это такая защита от совпадений разных страниц по одинаковому урлу.
Пока есть задача
Это "задача" - следствие СЕО-заблуждений :). Я бы даже сказал неграмотности. Нужно просто научится смотреть выдачу и тогда не будет ни волнений по пустякам ни поисков костыльных "решений".