Вообще, заказывая аппараты в Китае, не стоит забывать, что такие производители ориентируются на внутренний рынок. «Там у них» эта же компания совсем не ноунейм. Заказывая его из другой страны, в которой нет представительства, Вы соглашаетесь нести все риски при возникновении проблем — техобслуживание, прошивка и т.п.
Почитав те же обзоры на china-iphone я пришёл к выводу, что имеет смысл заказывать китайца только в том случае, если вы любите напильник, умеете им работать и это доставляет Вам удовольствие. И брать его нужно тогда, когда выходят стабильные версии прошивок, которые лечат аппарат от всех «детских болезней».
Это европейские бренды сначала долго вылизывают и тестируют аппарат и только потом выпускают его на рынок (и то не всегда — вспомните антенну 4го айфона). У китайцев же другая практика. Они выбрасывают на рынок готовое железо с ещё сырой прошивкой, которую будут ещё в течение приблизительно полугода обновлять до приемлемого состояния.
Я в своё время взял zp100 (и кстати ни разу не пожалел) только после того, как прочитал все обзоры и убедился в наличии готовых кастомных прошивок на любой вкус и цвет. В итоге когда аппарат приехал, я буквально за полчаса накатил на него все обновления, сделал вайп батареи и пользуюсь им в такой конфигурации до сих пор.
У меня был несколько иной путь — постепенное изучение с маленьких оплачиваемых проектов на базовой редакции, которые подкидывал один знакомый.
Потом потребовалось срочно пройти сертификацию для работы над крупным проектом. Пересилил себя и сидел штудировал учебные курсы, прошёл сертификацию (и, кстати, не жалею). Закончили крупный проект, получил денег и бесценный экспириенс, плюс сохранил сертификаты.
А дальше с таким багажом знаний устроился уже в студию, где был простор для экспериментов т.к. 90% проектов студии были на битриксе.
Для досконального изучения системы потребовался год работы, после чего я уволился т.к. понял, что изучать больше нечего и я начинаю тупеть на такой работе. Да и денег там много не платили.
А давайте выкатим базу в паблик (хотя бы урезанную, неполную версию) и докажем Вам, что всё возможно даже в таких условиях.
Просто я совершенно недавно решал задачу 1:1 c Вашей и решение было именно в индексах и грамотно поставленных запросах. PHP же производил минимальную обработку данных — банальные сортировки — и выдавал данные для построения графиков и таблиц. Причём на базе в over 1kk записей весь рендер на сервере и клиенте занимал от силы 3-4 секунды (период — год).
Я не говорю что битрикс как-то ограничивает, я лишь хочу сказать, все что выход за рамки стандартного функционала переносит в мир ужасного API, архитектуры и способствует написаю говнокода.
Если голова на плечах и руки из плеч, то всё путём =)
Если Вы в курсе всего этого, то извиняюсь. В начале сложилось ложное впечатление.
В запросе карточки товара содержится его ID или код и ещё пачка служебной информации — раздел, код инфоблока и т.п.
Что мешает в подключаемый файл сайдбара поставить компонент «сопутствующие товары» с параметром "ID" => $_REQUEST["ELEMENT_ID"]? То же самое с формой «Задать вопрос». В крайнем случае, если в стандартной комплектации нет компонента, на 100% отвечающего Вашим требованиям — никто не мешает его самостоятельно написать. И написать с нормальным AJAX, раз уж стандартная реализация Вас не устраивает.
Вас не устраивает Битрикс? Вы просто не умеете его готовить.
Вложу свои 5 копеек.
Тут очень многие пишут о том, что их утомляют ежедневные митинги и куча отчётности.
Приведу в пример нашу команду. Нет, мы не исповедуем Agile на 100%, но за пару месяцев у нас выработалась своя микрометодика.
Во-первых не стоит забывать, что Agile работает в командах по 5-8 человек. Это оптимальные цифры. Во-вторых, Agile — всего лишь инструмент коммуникации.
Когда мы проводим утренний митинг, мне на самом деле интересно, чем занимаются другие участники команды. И я могу внести ряд своих предложений в текущий план. А самое главное — я знаю кому я могу помочь здесь и сейчас поделившись своими знаниями (например, интересным трюком в CSS или какими-то познаниями в JavaScript) с остальными участниками команды, у которых в знакомых мне областях возникают сложности.
Это очень круто. Раньше, в других компаниях, использовавших классические методики управления, я не чувствовал себя настолько нужным, как чувствую сейчас.
Кроме того, всем и каждому видна динамика всего проекта в целом. Каждый участник команды знает, когда можно немного расслабиться и навернуть немножко «сахара» в проекте, а когда сжать сфинктер и потушить разгорающийся пожар.
Я олдфаг?
Почитав те же обзоры на china-iphone я пришёл к выводу, что имеет смысл заказывать китайца только в том случае, если вы любите напильник, умеете им работать и это доставляет Вам удовольствие. И брать его нужно тогда, когда выходят стабильные версии прошивок, которые лечат аппарат от всех «детских болезней».
Это европейские бренды сначала долго вылизывают и тестируют аппарат и только потом выпускают его на рынок (и то не всегда — вспомните антенну 4го айфона). У китайцев же другая практика. Они выбрасывают на рынок готовое железо с ещё сырой прошивкой, которую будут ещё в течение приблизительно полугода обновлять до приемлемого состояния.
Я в своё время взял zp100 (и кстати ни разу не пожалел) только после того, как прочитал все обзоры и убедился в наличии готовых кастомных прошивок на любой вкус и цвет. В итоге когда аппарат приехал, я буквально за полчаса накатил на него все обновления, сделал вайп батареи и пользуюсь им в такой конфигурации до сих пор.
Потом потребовалось срочно пройти сертификацию для работы над крупным проектом. Пересилил себя и сидел штудировал учебные курсы, прошёл сертификацию (и, кстати, не жалею). Закончили крупный проект, получил денег и бесценный экспириенс, плюс сохранил сертификаты.
А дальше с таким багажом знаний устроился уже в студию, где был простор для экспериментов т.к. 90% проектов студии были на битриксе.
Для досконального изучения системы потребовался год работы, после чего я уволился т.к. понял, что изучать больше нечего и я начинаю тупеть на такой работе. Да и денег там много не платили.
Просто я совершенно недавно решал задачу 1:1 c Вашей и решение было именно в индексах и грамотно поставленных запросах. PHP же производил минимальную обработку данных — банальные сортировки — и выдавал данные для построения графиков и таблиц. Причём на базе в over 1kk записей весь рендер на сервере и клиенте занимал от силы 3-4 секунды (период — год).
У нас на 7 человек хватает 10 минут.
Если голова на плечах и руки из плеч, то всё путём =)
Если Вы в курсе всего этого, то извиняюсь. В начале сложилось ложное впечатление.
Что мешает в подключаемый файл сайдбара поставить компонент «сопутствующие товары» с параметром
"ID" => $_REQUEST["ELEMENT_ID"]? То же самое с формой «Задать вопрос». В крайнем случае, если в стандартной комплектации нет компонента, на 100% отвечающего Вашим требованиям — никто не мешает его самостоятельно написать. И написать с нормальным AJAX, раз уж стандартная реализация Вас не устраивает.Вас не устраивает Битрикс? Вы просто не умеете его готовить.
Тут очень многие пишут о том, что их утомляют ежедневные митинги и куча отчётности.
Приведу в пример нашу команду. Нет, мы не исповедуем Agile на 100%, но за пару месяцев у нас выработалась своя микрометодика.
Во-первых не стоит забывать, что Agile работает в командах по 5-8 человек. Это оптимальные цифры. Во-вторых, Agile — всего лишь инструмент коммуникации.
Когда мы проводим утренний митинг, мне на самом деле интересно, чем занимаются другие участники команды. И я могу внести ряд своих предложений в текущий план. А самое главное — я знаю кому я могу помочь здесь и сейчас поделившись своими знаниями (например, интересным трюком в CSS или какими-то познаниями в JavaScript) с остальными участниками команды, у которых в знакомых мне областях возникают сложности.
Это очень круто. Раньше, в других компаниях, использовавших классические методики управления, я не чувствовал себя настолько нужным, как чувствую сейчас.
Кроме того, всем и каждому видна динамика всего проекта в целом. Каждый участник команды знает, когда можно немного расслабиться и навернуть немножко «сахара» в проекте, а когда сжать сфинктер и потушить разгорающийся пожар.
Рекомендую убрать в черновики и переписать в нормальную, читаемую статью.