Клиент всегда прав. С этим я не спорю =)
Люди всегда хотят купить дешевле и если есть возможность глупо ее упускать. Но ведь есть еще и жадность. Нужно ж купить много, раз оно на халяву, даже если это явно по ошибке системы.
Потом еще и друзьям расскажут.
Жаль только, что мало кто понимает, что в следующий раз они уже не смогут купить товар этого же продавца, даже если товар оказался качественный. Будут аналоги, но ведь чисто теоретически, можно угробить единственного качественного производителя.
Но это ни разу не оправдывает сервис, если он позволил цене опуститься до неадекватного значения. Есть куча способов предотвратить экстремальное падение/подъем цены или хотябы минимизировать ущерб. Но, судя по ситуации, небыло принято никаких мер предосторожности со стороны сервиса. В итоге пострадали продавцы, а сервис отделался легким испугом т.к. они «as is». По сути — халтуршики вышли сухими из воды, а трудяги, доверившиеся им, на грани банкротства. Поставьте себя на место пострадавших продавцов. Вот у вас есть бизнес, есть доход, все хорошо. А тут опа! И вы продаете большую партию товара, в который вложена куча денег и труда, за 1 пенни! Даже не за фунт, а за гребанный пенни! Вы понимаете что ваш бизнес накрылся медным тазом, куча людей, включая вас, теряет работу. Как вам? Еще хочется оправдывать сервис?
Ага. Вот это уже реальная причина того, почему продавцы потеряли деньги.
Все же удивительно насколько люди, управляющие бизнесом, беспечны и доверчивы. Хотя, возможно, никто не читал соглашения или не понял что as is это вообще никаких гарантий и ответственности. С другой стороны — халатность сервиса сравнения и выставления цен, которые допустили понижение цены ниже всех допустимых пределов. По идее автоматическая цена не должна была опустится ниже цены производства/закупки товара + минимальной наценки, которую продавец обязан был выставить, начиная работать с этим сервисом. Тут как ни крути, но минимальная допустимая цена есть, иначе бизнес не будет приносить доход, пусть даже минимальный. Да и сервис при резком понижении цены должен был запросить подтверждения у продавца игнорируя понижение цены пока продавец не утвердит ее.
Вообще не понятно как амазон, который живет за счет своей репутации, допустил к работе сервис не проведя его полное тестирование. От этого же зависит успешность не только сервиса, но и продавцов и самого амазона, которому со стороны продавцов теперь доверия сильно поубавится (тут уж многое зависит от итогов текущей ситуации, но репутацию они уже себе попортили). Надеюсь что сервис сравнения цен все-же будет наказан, а пострадавшие продавцы сохранят свой бизнес.
У меня есть глупые вопросы — почему продавцы не могут отменить заказы? Неужели репутация настолько важна, что ради нее нужно банкротиться? А если в законе прописано что продавец обязан выслать заказ вне зависимости от ситуации даже при мошенничестве (тут оно косвенное, но все же можно притянуть за уши), то тогда вообще какого хрена они заказы не обрабатывают вручную? Неужели люди сейчас настолько сильно доверяют автоматическим средствам, что даже не утруждают себя проверить какую цену эта система выставляет на товар? Неужели система не предоставляет возможность установить минимальную цену товара, ниже которой цена не должна опускаться? А если конкурент демпингует или специально занижает цену выставляя малое количество товара чтобы конкуренты ушли в минус? Да кто вообще доверяет ПО, которе распространяется as is и имеет право выставлять цену на товар? Что это вообще за идиотизм такой?
Я вот совсем не понимаю зачем урезать левый шифт? Он же как бы более востребован и привычен чем правый, почему не урезать правый? Причем впихивают же кнопку "\|", которая ну аж ни разу там не ожидается. Тот, кто привык к стандартной раскладке — это ж сущий ад. Вместо шифта попадаешь на эту долбанную клавишу. Причем я шифт нажимаю четко там, где эта клавиша… В итоге очередная бесполезная клавиатура получается =(
Лучше бы сделали что-то полезное полу-эргономичное. Я вот все жду чего-то наподобии Genius GK04008 (ErgoMedia 700). Я таких уже 4 штуки за 7 лет убил, но лучше все никак найти не могу.
Ура! +1 к армии перешедших на постгрес! =) Я после постргеса мускл использую только для небольших сайтов, где база по сути нужна только для хранения небольшого количества инфы, не больше. + страхую эту систему 80-100% кешированием в память ибо ну его тот мускл с его приколами к чертям =). Иногда даже использую sqlite + cache вместо mysql, если совсем уж сайтик прост
Я пока не заметил в postgresql косяков с таймзонами, так что можно вполне уверенно их использовать. Нативное почти всегда лучше. Тем более в постгресе куча плюшек для работы со временем =)
Ну или забыть наконец про mysql и юзать postgresql, где работать с датами можно нативно, включая таймзоны. Есть нативная функция timezone('GMT+3', ts). В добавок: не нужно хранить таймзону в отдельном поле — есть спец тип: timestamp with timezone для этого. И конвертирование вдругие таймзоны еще проще. Единственное что нужно всегда помнить: функция timezone по-разному работает для типов ts with tz и для ts without tz, тут можно немного накосячить если не понимать разницу.
Проблемы появляются только когда происходит незапланированный во всем мире переход в другую зону как в этом году с Россией. Тут начинаются косяки с зонами типа «Europe/Moscow» т.к. сдвиг для них не обновился. Тут уж ничего не поделаешь — нужно ручками в БД править. Если не ошибаюсь, то от рута в postgresql можно исправить сдвиг прямо во встроенной в postgresql таблице таймзон (не помню уже как она называется, но она точно есть в виде обычной таблицы бд + расположена она не в схеме public)
Если сделать более-менее постоянный, но при этом большой плейлист, то со временем музыка начнет отгораживать тебя от внешнего мира не создавая значительной доп. нагрузки. Я ее вообще перестаю слушать когда решаю какую-то задачу. Она как бы работает в фоне, задает ритм. Единственное что реально утомляет — это сами наушники. Я заметил что слушая музыку через колонки я не устаю вообще, в то время как в наушниках усталость все-же есть, но не от музыки. Есть мнение что проблема в проводе и привязке к чему-то. Надо будет попробовать блютусные наушники.
Согласен. Хотя обычно они не связаны слишком сильно. У меня же получилось так, что sql-генератор проверяет нет ли в запросе неизвестных полей (берет он их из конфигов модели) и назначены ли кастомным полям типа COUNT(*) алиасы. Также умеет делать join'ы по названию модели беря данные о связи из конфига модели. Его теперь без напильника отдельно от всего ORM не поиспользуешь. Зато удобно =)
Для SQL у меня тоже есть свой велосипед больше похожий на ORM, правда. Хотя 1 из компонентов — сборщик sql запросов DbQuery::create(table, alias)->fields('*')->where(array())->run() и т.д. Ситуация была такая, что нужно было сделать максимально вредный ORM, который умел бы превращать ответы из БД в объекты и наоборот. Валидация, конвертация типов (для timestamp, например), максимально простое прикрепление файлов и получение путей к ним и т.п. Все поля, естественно, должны быть описаны в конфигах
Фишка в том, что ORM должен вылетать с исключениями на каждый непонравившийся ему момент. Ну а любое исключение отправляется мне на email. Идея в том, чтобы предотвратить неадекватные или ошибочные действия с данными. Например, если в объект не загружено поле, но я к нему обращаюсь — получу исключение на почту. Ибо нефиг.
Платформонезависимостью не похвастаюсь, но она «условно» есть =) Просто я не проверял на других БД, кроме PostgreSQL
Если у вас оно сходу преобразовывается в строку, то да, моё творение жрет больше. Зато позволяет себя модифицировать далее в коде (а это весьма полезно бывает).
К тому же если использовать echo HtmlTag::a(), то получится примерно одинаково т.к. объект сразу превратится в строку (методом __toString()) и на него не останется ссылок (т.е. сборщик мусора его грохнет).
Разница в расходе памяти тут будет зависеть от реализации.
У меня как раз на php-doc и завязаны все вызовы HtmlTag::tagName(). Тегов и атрибутов на самом деле не так уж и много.
А разве в h::{'input[id=$i[id]][type=checkbox][checked=$i[value]][value=1]'}() строка 'input[id=$i[id]][type=checkbox][checked=$i[value]][value=1]' не парсится?
Ммм… После того как я изобретал свой шаблонизатор я очень негативно отношусь к парсингу строк для генерации кода. Много проблем может возникнуть + никаких подсказок от IDE.
Еще заметил что полностью генерировать весь html неудобно. Визуально много бесполезного шума получется. Остановился на варианте генерации html кода где нужно совмещать пхп-код с html-тегами. Так получается наиболее оптимально.
Мой велосипед менее функционален, но при этом более прост в использовании и не требует никакого знания спец-вставок и их парсинга.
Примеры:
1. HtmlTag::a('content')->href('/url')->class('abc');
2. HtmlTag::a(array('content' => 'text', 'href' => '/url', 'class' => 'abc'))
В чем преимущества:
— никакого парсинга входных строк что сильно уменьшает количество возможных багов и ускоряет генерацию кода
— В примере 1 будут подсказки аттрибутов от IDE, что значительно ускоряет написание
— В content можно передавать другие теги
— Можно модифицировать аттрибуты и контент когда угодно и где угодно т.к. мы работаем с объектом (также есть методы append и prepend для контента, addClass для классов и некоторые другие помогалки)
— Можно легко делать компоненты унаследовав класс HtmlTag. Что я и сделал для form и input, textarea, select тэгов, получив весьма удобный генератор форм с минимальными запарами.
Недостатки:
— нет автоматизации для массивов данных (хотя, вероятно, я ее добавлю ибо очень уж полезная идея)
Согласен, что там может быть 2 одинаковых документа, но находятся-то они в разных корневых ресурсах. Причем часто они будут отличатся.
Как по мне инкрементировать версию апи имеет смысл если новая версия ресурсов значительно отличется от старой версии ресурсов. Добавляя новые русурсы нет смысла увеличивать версию апи. Поэтому меньшее количество ресурсов будут отдавать одинаковые данные.
На тему гитхаба — удобный, но далеко не всем проектам нужно изменять версию часто, т.е. опять же метод «не для всех».
И, кстати, ничто не мешает в обоих случаях использовать другу версию api. И, кстати, с точки зрения клиента проще использовать url, чем использовать один хедер для запросов к новому апи, а другой для запросов к старому апи. Шанс накосячить из-за невнимательности возрастает.
Тут как бы нет «серебрянной пули», каждый метод имеет свои плюсы и минусы. Нужно лишь правильно оценить потребности.
А что такое API? Разве API — не ресурс?
В моем понимании — API это корневой ресурс, который предоставляет доступ к другим ресурсам. Да, согласен, что другие ресурсы не принадлежат API физически (в БД или ФС), но оно все же не перестает быть ресурсом.
Так про успешность и не говорим. Она мало зависит от версионирования апи, если апи само по себе толковое.
Тут скорее вопрос в простоте реализации для клиента и для сервера. И вариант с версией в url наиболее понятен и прост в реализации для всех сторон. Единственная сложность может возникнуть с минорными версиями типа «1.1», но это вообще плохая затея как по мне.
Люди всегда хотят купить дешевле и если есть возможность глупо ее упускать. Но ведь есть еще и жадность. Нужно ж купить много, раз оно на халяву, даже если это явно по ошибке системы.
Потом еще и друзьям расскажут.
Жаль только, что мало кто понимает, что в следующий раз они уже не смогут купить товар этого же продавца, даже если товар оказался качественный. Будут аналоги, но ведь чисто теоретически, можно угробить единственного качественного производителя.
Все же удивительно насколько люди, управляющие бизнесом, беспечны и доверчивы. Хотя, возможно, никто не читал соглашения или не понял что as is это вообще никаких гарантий и ответственности. С другой стороны — халатность сервиса сравнения и выставления цен, которые допустили понижение цены ниже всех допустимых пределов. По идее автоматическая цена не должна была опустится ниже цены производства/закупки товара + минимальной наценки, которую продавец обязан был выставить, начиная работать с этим сервисом. Тут как ни крути, но минимальная допустимая цена есть, иначе бизнес не будет приносить доход, пусть даже минимальный. Да и сервис при резком понижении цены должен был запросить подтверждения у продавца игнорируя понижение цены пока продавец не утвердит ее.
Вообще не понятно как амазон, который живет за счет своей репутации, допустил к работе сервис не проведя его полное тестирование. От этого же зависит успешность не только сервиса, но и продавцов и самого амазона, которому со стороны продавцов теперь доверия сильно поубавится (тут уж многое зависит от итогов текущей ситуации, но репутацию они уже себе попортили). Надеюсь что сервис сравнения цен все-же будет наказан, а пострадавшие продавцы сохранят свой бизнес.
Лучше бы сделали что-то полезное полу-эргономичное. Я вот все жду чего-то наподобии Genius GK04008 (ErgoMedia 700). Я таких уже 4 штуки за 7 лет убил, но лучше все никак найти не могу.
Проблемы появляются только когда происходит незапланированный во всем мире переход в другую зону как в этом году с Россией. Тут начинаются косяки с зонами типа «Europe/Moscow» т.к. сдвиг для них не обновился. Тут уж ничего не поделаешь — нужно ручками в БД править. Если не ошибаюсь, то от рута в postgresql можно исправить сдвиг прямо во встроенной в postgresql таблице таймзон (не помню уже как она называется, но она точно есть в виде обычной таблицы бд + расположена она не в схеме public)
COUNT(*)алиасы. Также умеет делать join'ы по названию модели беря данные о связи из конфига модели. Его теперь без напильника отдельно от всего ORM не поиспользуешь. Зато удобно =)DbQuery::create(table, alias)->fields('*')->where(array())->run()и т.д. Ситуация была такая, что нужно было сделать максимально вредный ORM, который умел бы превращать ответы из БД в объекты и наоборот. Валидация, конвертация типов (для timestamp, например), максимально простое прикрепление файлов и получение путей к ним и т.п. Все поля, естественно, должны быть описаны в конфигахФишка в том, что ORM должен вылетать с исключениями на каждый непонравившийся ему момент. Ну а любое исключение отправляется мне на email. Идея в том, чтобы предотвратить неадекватные или ошибочные действия с данными. Например, если в объект не загружено поле, но я к нему обращаюсь — получу исключение на почту. Ибо нефиг.
Платформонезависимостью не похвастаюсь, но она «условно» есть =) Просто я не проверял на других БД, кроме PostgreSQL
К тому же если использовать
echo HtmlTag::a(), то получится примерно одинаково т.к. объект сразу превратится в строку (методом __toString()) и на него не останется ссылок (т.е. сборщик мусора его грохнет).Разница в расходе памяти тут будет зависеть от реализации.
А разве в
h::{'input[id=$i[id]][type=checkbox][checked=$i[value]][value=1]'}()строка'input[id=$i[id]][type=checkbox][checked=$i[value]][value=1]'не парсится?Еще заметил что полностью генерировать весь html неудобно. Визуально много бесполезного шума получется. Остановился на варианте генерации html кода где нужно совмещать пхп-код с html-тегами. Так получается наиболее оптимально.
Мой велосипед менее функционален, но при этом более прост в использовании и не требует никакого знания спец-вставок и их парсинга.
Примеры:
1.
HtmlTag::a('content')->href('/url')->class('abc');2.
HtmlTag::a(array('content' => 'text', 'href' => '/url', 'class' => 'abc'))В чем преимущества:
— никакого парсинга входных строк что сильно уменьшает количество возможных багов и ускоряет генерацию кода
— В примере 1 будут подсказки аттрибутов от IDE, что значительно ускоряет написание
— В content можно передавать другие теги
— Можно модифицировать аттрибуты и контент когда угодно и где угодно т.к. мы работаем с объектом (также есть методы append и prepend для контента, addClass для классов и некоторые другие помогалки)
— Можно легко делать компоненты унаследовав класс HtmlTag. Что я и сделал для form и input, textarea, select тэгов, получив весьма удобный генератор форм с минимальными запарами.
Недостатки:
— нет автоматизации для массивов данных (хотя, вероятно, я ее добавлю ибо очень уж полезная идея)
Как по мне инкрементировать версию апи имеет смысл если новая версия ресурсов значительно отличется от старой версии ресурсов. Добавляя новые русурсы нет смысла увеличивать версию апи. Поэтому меньшее количество ресурсов будут отдавать одинаковые данные.
На тему гитхаба — удобный, но далеко не всем проектам нужно изменять версию часто, т.е. опять же метод «не для всех».
И, кстати, ничто не мешает в обоих случаях использовать другу версию api. И, кстати, с точки зрения клиента проще использовать url, чем использовать один хедер для запросов к новому апи, а другой для запросов к старому апи. Шанс накосячить из-за невнимательности возрастает.
Тут как бы нет «серебрянной пули», каждый метод имеет свои плюсы и минусы. Нужно лишь правильно оценить потребности.
В моем понимании — API это корневой ресурс, который предоставляет доступ к другим ресурсам. Да, согласен, что другие ресурсы не принадлежат API физически (в БД или ФС), но оно все же не перестает быть ресурсом.
Тут скорее вопрос в простоте реализации для клиента и для сервера. И вариант с версией в url наиболее понятен и прост в реализации для всех сторон. Единственная сложность может возникнуть с минорными версиями типа «1.1», но это вообще плохая затея как по мне.