Да модераторы мудаки. Написал полный развернутый вопрос. Удалили. Написал короткий - пропустили.
Еще раз суть задачи: необходимо балансировать нагрузку загрузки файлов по нескольким серверам. Можно ли это как то сделать на PHP?
"При обращении в студии с репутацией, оказывался в конце очереди с ожиданием в 2-3 месяца."
И это нормально) И даже хорошо)
Только непрофессиональные студии готовы сделать вам "вчера", не имеют планирования, и пытаются впихнуть на свои ресурсы в какие нибудь 1000 человекочасов/в неделю двойной объем работы. Ничего хорошего из такого не выходит в 90% случаев) Это факапы, баги, и куча нервов как заказчику так и исполнителю.
Многие компании с имеющейся системой планирования готовы пойти на встречу, и пропихнуть ваш проект "без очереди", за доп плату (которой компенсируют переработки сотрудникам).
Ну и конечно важен объем и сложность вашей задачи. Если задача часов на 20, то обычно долго ждать не приходится, у многих есть свой отдел "саппорта", который и создан для кратковременных задач. Однако не у всех он есть, есть разные бизнес модели, к примеру студии ориентированные только на production, у таких вы можете даже для маленькой задачи ждать долго.
Если же у вас задача на несколько сотен человекочасов, нужно быть совсем упертым бараном чтобы считать что вы придете в студию, где все только "хрен пинают", и готовы сразу приступить к работе которая "наконец то" к ним пришла) Разумеется вы получите некоторую очередь.
Фрилансеров вообще не стоит упоминать. На этом рынке вам очень повезет если вы найдете надежного исполнителя. Вне зависимости от задачи которую необходимо вам решить.
Однако несмотря на несуразный пример, который вы привели в доказательство, ваш вывод немного попал в точку в формулировке.
Действительно Bitrix не достаточно хорошо заботилась о качестве работы партнеров. И это долгое время длилось, просто отсутствовала "культура" разработки среди партнеров.
Однако все меняется, и культура помимо того что прорастает сама (опять же в топовых студиях), уже и активно насаждается сверху. На этой неделе выкатились обязательные требования к "партнерству" в виде экзаменирования разработчиков с такими вот требованиями: training.1c-bitrix.ru/upload/exam_dev/pubinfo/exam...
"Важен не сам факт PR, а то, кто рекламирует этот продукт"
Да в принципе ВСЕ так делают, как платные так и бесплатные CMS. Те студии которые работают с друпалом - будут всячески нахваливать сам друпал. Те кто с modx - modx, те кто с UMICMS - будут хвалить UMI. Те кто пишут самописные системы будут продавливать преимущества последних.
Откаты у битрикса очень малы, они составляют жалкие единицы процентов от прибыли проекта разработчику, я бы не назвал это значимой частью, если вы подумаете о них.
Эффективность их PR модели в ее агрессивности и интенсивности. Они просто куда как активнее действовали и действуют чем другие игроки. Очень выгодный контракт с 1с, и оф. поддержкой развивающейся интеграции с 1сками - также один САМЫХ главных факторов выбора системы для заказчика. Хотя для многих заказчиков уже только одна приставка 1с - придает ему больше веса.
Каким образом к примеру chrome стал самым популярным браузером, вышев на рынок с нуля?
а) Дохрена рекламы. Вспомните когда на каждом сайте торчал баннер хрома кричащий о его скорости.
б) Приемлемое качество.
Ни одна другая CMS себя так агрессивно не вела на нашем рынке, потому никто и не урвал себе такой жирный кусок.
Но в общем соглашусь с общей логикой ответа:
У Битрикса впереди идет мощный PR, а качество уже догоняет.
Но по качеству уже ни 1 коммерческая cms во всем мире* не может с ним сравниться.
* - в 2015 году, битрикс вошел в топ 7 мировых CMS, и стал топ 1 коммерческой cms в мире.
Что то в финальной строчке ответа есть)
Но работать со всем подряд с большим количеством переключений и писать на всем качественный код который соответствует архитектуре и парадигме продукта - сложно.
Лучше взять 1, максимум 2 продукта (я бы посоветовал CMS+FW) и работать с ними, стать в них спецом.
Иначе о качественном выполнении интересных (сложных) задач можно забыть.
В IT сообществе bitrix тоже понемногу отвоевывает кусок) Мне кажется реальности рано или поздно сольются) Хотя тех кто его не любит еще долго будет хватать)
Проблема "не быстрого" устранения недостатков в том что они практически единственный игрок который на рынке который сохраняет обратную совместимость для своего продукта уже более 10 лет. За это их и любит бизнес.
Было бы куда проще и быстрее переписать, завставив весь бизнес выкатить кучу бабла чтобы перейти на новую версию.
Ну и само собой чтобы расти и держать позицию на рынке они каждые пол года выкатывают новый вагон фич, а не занимаются одним только реврайтом ядра.
Потому процесс не быстрый, с этим только смириться.
Bitrix использует apache, nginx, php, mysql/mssql/oracle, memcached, sphinx. Можно еще за уши притянуть что нибудь.
Хотя мб автор имел ввиду другое понятие, термин "технологии" достаточно широк.
Александр Шпелев: Все верно, 8 место.
Причем важно отметить вектор "вверх", они каждый год набирают позиции.
Хотя до объема magento на мировом рынке конечно не дорос.
Но тут стоит задаться автору вопроса: хочет он разрабатывать на аутсорс на зарубеж, или работать в штате компании в России.
imdeveloper: Не стоит поройть ахинею, битрикс писался крупной командой людей в течении десяти лет. В одиночку такого монстра не осилить за всю жизнь.
zooks:
Думаю мой комментарий основанный на личном опыте образумит некоторых от выбора непопулярных, менее перспективных направлений. Порой популизм в отношении критики технологий которые занимают и будут занимать большую(или бОльшую) нишу на рынке играют дурную роль в отношении людей которые не знают рынок.
Выбор технологического стека для разработки должен делать осознанно:
1. Я пойду писать на менее популярном и востребованном на рынке стеке, но зато буду писать уже сейчас на более приятном фреймворке. И я полностью осознаю что могу меньше получать, могу иметь проблемы с поиском работы особенно штатной в своем городе/регионе.
2. Я пойду на стек технологий который будет однозначно востребован в ближайшие 5-10 лет, осознавая некоторые временные трудности развивающегося фреймворка.
Новичку я бы посоветовал пойти на популярный стек, а дальше уже по желанию.
Я юзаю: ConEmu + Clink (авто-дополнение путей ласт версия) + при установке GIT ставятся в винду часть портированных утилит юниксовых.
Ниче так выходит)
У ConEmu кайфовая настройка с quake-style wrap, не пропустите ;)
В принципе есть так: 1 дизайнер и 3 free-lance. Но тот который в штате - для всех удобнее и надежнее. Потому основная конкуренция идет за ресурсы именно штатного дизайнера.
Вопрос в методологии/модели по которой выстраивать ограничения для ПМ на штатного дизайнера)
Она собрана - большинству кажется что без ПМ будет лучше)
Но ведь может кто то даст другой взгляд - к примеру уже пробовали расселять и профита не получили =)
Еще раз суть задачи: необходимо балансировать нагрузку загрузки файлов по нескольким серверам. Можно ли это как то сделать на PHP?