Dark_Dante: Копирование данных при оформлении заказа стандартная практика. Дело в том, что эти сведения необходимы в дальнейшем для разного рода анализа. А текущий ассортимент довольно часто меняется, могут обновить название или картинку или еще что-нибудь поменять.
Например бывают ситуации, когда человек заказал что-нибудь и в описании была ошибка, человек получил не то, что хотел. Пока товар доставлялся, ошибку исправили, но претензия клиента появилась уже после этого. И только полное копирование данных заказа помогает решить подобные проблемы.
Плюс есть разного рода анализ цен, например можно выявить сезонные изменения цены у поставщика и заказывать больше товара тогда, когда на него низкая цена.
d-virt: d3 работает с svg. Это по сути и есть генератор SVG изображений. У меня коллега довольно сложные графики на нем строил, плюс добавлял к ним разную анимацию. Выглядело классно и работало быстро даже на телефоне.
Первый iPhone тоже был ужасным продуктом, но в нем была решена проблема отзывчивости интерфейса - т.е. производительности. В то время уже были наработки сенсорных телефонов, но все имели тормоза.
Если продукт будет неудобен в использовании при наличии удобных аналогов - им никто не будет пользоваться.
Если интересно, то gojs мне показался неудобным. При перетаскивания и масштабировании появляется какое-то мыло на тексте. В тоже время d3 работает просто чудесно.
sim3x: продукт может не взлететь из-за того, что производительность плохая. Для средств рисования это один из критических параметров. Наглядный пример - попытка заменить планшетом бумагу. Единственная более-менее удачная попытка это самый последний iPad Pro.
d-virt при разработке подобного продукта следует проанализировать предметную область, посмотреть на другие продукты. Клиенты, которые могут принести вашему бизнесу деньги будут иметь сложность на уровне выше 1000 элементов в модели.
Лично я бы рекомендовал смотреть в сторону SVG поскольку это изначально векторный формат, поэтому вещи вроде масштабирования или копирования будут намного проще.
Ставите XHPROF, настраиваете. Потом вызываете его внутри вашего проекта. Он генерит вам ID отчета, потом просто смотрите отчет. Ему еще надо www.graphviz.org поставить, чтобы он мог вызвать dot внутри.
Dave: в больших проектах для них применяют так называемое объектное хранилище. Оно представляет собой некую абстракцию над файловой системой и сервис, который отдает эти файлы наружу. Есть несколько разных вариантов, таких как AWS S3, Riak-S2 или тот же GridFS.
Dark_Dante: какая-то странная реализация. Обычно после заказа запись удаляется из корзины.
Если хотите реализовать это правильно, нужно делать с использованием транзакции. Т.е. открываете транзакцию, создаете заказ, далее резервируете товар на складе, добавляете товар в заказ и т.д. пока все (выбранные) товары не попадут в заказ. Если товара не хватает, откатываете транзакцию. В таком случае и данные будут впорядке и покупатель увидит, что нет какого-то товара и примет решение, продолжать или не стоит.
На мой взгляд он вполне себе тоненький.
На ajax/long-polling нормальный чат сделать сложно.
Нет, вы конечно можете бомбить свой сервер каждые 5 секунд в мертвом цикле на клиенте или создавать висящие процессы на сервере.
Чат на сокетах наиболее эффективное решение, а вот геморрой как раз поддерживать открытые по HTTP соединения или справляться со штормом запросов.
SV999Z: это да. Но ведь не все проекты длятся месяц-другой. Есть проекты, которые разрабатываются годами. В них приходят люди и из них уходят люди. И ответственность за состояние проекта лежит на всех - разработчиках, тим лиде и даже CTO. Каждый привносит свой вклад на разных уровнях.
Кто-то должен это все грамотно проектировать, кто-то писать код по стандартам. Иногда бывает так, что нормальные комментарии сделать некогда и в таких случаях только следование методологии правильного именования объектов/методов помогает, автокомплит просто спасает.
