Я до того как появился node.js писал серверсайд исключительно на Perl. Не фанатизм, просто так сложилась судьба. Но работы из года в год меньше не становится. Предсмертных конвульсий пока не наблюдал.
Ещё один простой и эффективный тест по теме, из личной практики.
В 1С есть стандартная функция выгрузки прайса. «Напечатать прайс» — как-то так, не помню точно. Вы просто спрашиваете у потенциального заказчика, может ли он сейчас, вызвав эту функцию, получить прайс который ему будет не стыдно положить на стол его покупателям/клиентам.
Если нет, если «ну у нас там нюансы в базе» — похороните все мечты, что вы обойдётесь стандартными загрузками. Этому не бывать. Там как минимум вас ждут нюансы. Им есть там где быть: по ценообразованию, складской учёт (будь он неладен), кое-где задвоенная номенклатура, и ещё что- нибудь от чего их штатный 1С-программист спит некрепким сном.
Задача связать сайт с 1С — это вскрытие многих косяков в работе 1С-ника. Не всем это понравится, от сюда и соответствующее поведение «отстранённого 1С-гуру» который на деле саботирует процесс. Очень мало профессионалов которые сядут и вместе с вами разработают структуру передаваемых данных и согласуют её, естественно письменно.
Ваш случай, к сожалению, типовой. Всё упирается в то, что у клиента попросту база не может быть выгружена нормально, т.к. по остаткам там адъ и много проведённого задним числом.
1. На счёт разговора веб-разработчика и 1С-ника, тоже чистая правда. Со своим 1С спецом работаю уже 8-й год, но и то бывают пробуксовки. Когда писал SOAP библиотеку на Perl для вызова внутренних процедур 1С — мы оба чуть не рехнулись. У него всё работает, а КАК оно работает на уровне HTTP протокола он не знает. И обвинить его ни в чём нельзя — более высокоуровневое программирование. Мне пришлось писать снифер, который ловил передаваемые 1С-кой данные.
С другой стороны это ещё цветочки. Мы вместе собственно потому и работаем что в целом нашли общий язык и клиент не страдает от проблем нашего взаимопонимания.
2. Лично убедился что этот пункт сильно зависит от компетенции даже не админа, а 1С-ника. Один сам сделает так, что 1С и выгрузку по расписанию сделает, и по FTP всё на сайт выложит, и скриптину-обработчик сама дёрнет, а то и вообще по ODBC прямо на SQL-сервер всё сайта зальёт. А другой с умным видом кинет CSV по почте — и попробуй ещё спасибо не скажи.
Если вы простой менеджер в шаровой конторе которая принципиально берётся за всё, ибо такова политика руководства — у вас может не быть шансов «уволить клиента» не будучи уволенным самому. А может и быть. Зависит от политики в этой компании.
Но честно, вот тот кошмар который описывает автор топика, он по какой причине стал явью? Почему клиента не развернул и не пожелали удачи? Видимо всё-таки были обстоятельства заставляющие взяться за откровенно клинический случай. Что-то же не позволило «уволить клиента»?
Одним из очевидных плюсов фриланса, является право «уволить клиента». Если уже наработано портфолио и репутация и есть постоянный поток заказчиков, то появляется возможность управлять описанными в топике рисками.
У менеджера в студии может просто не быть шанса отказать «клиенту-идиоту». И это печально опыт.
1. Услуги 1С-ника выносятся из проекта в отдельный договор. Потому как практически всегда начальная задача «нужна выгрузка» превращается в отдельную задачу «но сначала надо… привести в порядок базу… инвентаризация… (и где-то через месяц) ...».
2. ТЗ на разработку сайта содержит минимум 2 этапа: эскизное проектирование и вёрстка+программинг. В ТЗ чётко пишется, что второй этап, он конечно наступает по плану такого-то числа, но если к этому моменту выгрузка не будет предоставлена, то второй этап откладывается на столько на сколько мы ждём выгрузки. Это при том, что над выгрузкой работает наш же специалист.
Это позволяет клиенту тоже почуствовать ответственность за сроки проекта. Я работаю с весьма грамотным 1С-ником, поэтому как только он начинает работать с клиентом, у того обычно отпадает желание катить бочку на пустом месте. Сориться со спецом который решает ему очевидные проблемы с учётной системой клиент уже не хочет. Если заказчик неадекватен на столько чтобы такое вытворять, то это проявляется ещё на предпродажах, и ТЗ с такими заказчиками даже не появляется на свет.
Вообще, главное в этих проектах не испытывать иллюзий самому, и как можно быстрее возвращать клиента на землю. Тут всё просто, либо он понимает что есть объективные проблемы, но есть и Исполнитель в нашем лице, который их решит, либо клиент ищет кого-то ещё, а мы берёмся за следующий проект.
Я уверен что уже есть и будет ещё написана куча подобных инструментов. Но моя цель была решить конкретную задачу, а не попробовать всё что только можно. Результат работы forever меня более чем устроил.
Если у вас есть решение на базе supervisord — поделитесь. Напишите в чём плюсы, в чём минусы. Это всегда интересно.
Есть ещё один нераскрытый в статье нюанс. На моей личной практике, из 14 случаев интеграции с 1С, предварительные работы по приведению в порядок клиентской базы моим 1С специалистом не проводились только 1 раз. И то потому, что мой специалист 1С эту базу изначально и сопровождал. Во всех остальных случаях работы занимали от нескольких недель до 4 месяцев (!).
Особенно тревожный признак — когда клиент уверенно говорит что ему необходимо показывать на сайте остатки. В 95% случаев это означает, что нас ожидает период ожидания пока клиент не проведёт качественную, полную инвентаризацию.
Если клиент отказывается от услуг моего специалиста, и сообщает, что у него есть свой штатный программист, то я принимаю решение о работе над проектом только после личного контакта с его программистом.
Если программиста прячут, если контакта с ним нет, если стрелка его ЧСВ пробила приборную панель, то просто идём дальше. Потому что примеры автора топика уже оставили глубокий кровоточащий экспиренс в моей нервной системе. Такие заморочки практически ни когда на бывают оплачены адекватно. а опыт таких ситуаций ценен только одним — получением навыков избегать их повторения.
А вообще, я в таких проектах сразу довожу до клиента, что мы не просто решаем задачу создать ему каталог. Задача намного шире. В результате проведённых работ мы так или иначе будем вынуждены привести в порядок его учётную систему.
Описанное решение позволяет запускать каждый node-процесс отдельно, вы просто создаёте для каждого процесса свой rc.d скрипт. Плюс в том, что rc.d позволяет вам прописать зависимости и обеспечить старт процессов в нужном порядке. При этом с forever у вас всегда остаётся централизованный инструмент для оценки состояния всех запущенных процессов, а также их группового перезапуска / остановки.
Я предпочитаю самостоятельно управлять этим таймстампом добавляя в запрос параметр nocache:1328733099144. Но в описанном мною выше решении, я как раз при обращении с файлу с лентой событий подставляю таймстамп полученный из первого файла: {«fresh»:1328202452}. Таким образом я могу снизить реальную нагрузку на сервер в момент коллективного старта о котором вы писали. Основная масса клиентов запросив повторно данные из файла-ленты, при таком подходе, просто получит их из кеша своего браузера.
Отключение кеша — не самый хороший метод. С кешем не надо бороться, его надо использовать. Но я не в курсе деталей вашей задачи, поэтому может ваше решение вполне рабочее.
Они будут ломиться за статическим файлом, который отдаст nginx. Никакой блокирующей нагрузки, в виде исполнения кода на сервере и обращения к БД при этом не будет. Единственный минус который проявился для такого решения — данные в файле дублируют данные в БД. Но если в файле хранится уже агрегированные данные, например результат запроса в БД с джойнами, то про дублирование уже как-то и не беспокоишься. База не дёргается, данные отдаются с минимальной нагрузкой на сервер — что ещё надо?
Я где-то пару лет периодически использую такую схему:
Два статических JSON файла. Один содержит ленту событий отслеживаемую клиентом, второй является хранилищем unix timestamp вида {«fresh»:1328202452}. Клиент опрашивает простым полингом файл с таймстампом, и при его изменении запрашивал основной файл. Вся прелесть этого решения дополняется nginx-ом, который эту статику весьма бодренько отдает. Операции с БД происходят только в момент записи новых данных. В случаях когда данные в БД поступают намного реже чем читаются, данный метод работает наиболее эффективно.
В 1С есть стандартная функция выгрузки прайса. «Напечатать прайс» — как-то так, не помню точно. Вы просто спрашиваете у потенциального заказчика, может ли он сейчас, вызвав эту функцию, получить прайс который ему будет не стыдно положить на стол его покупателям/клиентам.
Если нет, если «ну у нас там нюансы в базе» — похороните все мечты, что вы обойдётесь стандартными загрузками. Этому не бывать. Там как минимум вас ждут нюансы. Им есть там где быть: по ценообразованию, складской учёт (будь он неладен), кое-где задвоенная номенклатура, и ещё что- нибудь от чего их штатный 1С-программист спит некрепким сном.
Задача связать сайт с 1С — это вскрытие многих косяков в работе 1С-ника. Не всем это понравится, от сюда и соответствующее поведение «отстранённого 1С-гуру» который на деле саботирует процесс. Очень мало профессионалов которые сядут и вместе с вами разработают структуру передаваемых данных и согласуют её, естественно письменно.
1. На счёт разговора веб-разработчика и 1С-ника, тоже чистая правда. Со своим 1С спецом работаю уже 8-й год, но и то бывают пробуксовки. Когда писал SOAP библиотеку на Perl для вызова внутренних процедур 1С — мы оба чуть не рехнулись. У него всё работает, а КАК оно работает на уровне HTTP протокола он не знает. И обвинить его ни в чём нельзя — более высокоуровневое программирование. Мне пришлось писать снифер, который ловил передаваемые 1С-кой данные.
С другой стороны это ещё цветочки. Мы вместе собственно потому и работаем что в целом нашли общий язык и клиент не страдает от проблем нашего взаимопонимания.
2. Лично убедился что этот пункт сильно зависит от компетенции даже не админа, а 1С-ника. Один сам сделает так, что 1С и выгрузку по расписанию сделает, и по FTP всё на сайт выложит, и скриптину-обработчик сама дёрнет, а то и вообще по ODBC прямо на SQL-сервер всё сайта зальёт. А другой с умным видом кинет CSV по почте — и попробуй ещё спасибо не скажи.
3. истинно.
Но честно, вот тот кошмар который описывает автор топика, он по какой причине стал явью? Почему клиента не развернул и не пожелали удачи? Видимо всё-таки были обстоятельства заставляющие взяться за откровенно клинический случай. Что-то же не позволило «уволить клиента»?
У менеджера в студии может просто не быть шанса отказать «клиенту-идиоту». И это
печальноопыт.1. Услуги 1С-ника выносятся из проекта в отдельный договор. Потому как практически всегда начальная задача «нужна выгрузка» превращается в отдельную задачу «но сначала надо… привести в порядок базу… инвентаризация… (и где-то через месяц) ...».
2. ТЗ на разработку сайта содержит минимум 2 этапа: эскизное проектирование и вёрстка+программинг. В ТЗ чётко пишется, что второй этап, он конечно наступает по плану такого-то числа, но если к этому моменту выгрузка не будет предоставлена, то второй этап откладывается на столько на сколько мы ждём выгрузки. Это при том, что над выгрузкой работает наш же специалист.
Это позволяет клиенту тоже почуствовать ответственность за сроки проекта. Я работаю с весьма грамотным 1С-ником, поэтому как только он начинает работать с клиентом, у того обычно отпадает желание катить бочку на пустом месте. Сориться со спецом который решает ему очевидные проблемы с учётной системой клиент уже не хочет. Если заказчик неадекватен на столько чтобы такое вытворять, то это проявляется ещё на предпродажах, и ТЗ с такими заказчиками даже не появляется на свет.
Вообще, главное в этих проектах не испытывать иллюзий самому, и как можно быстрее возвращать клиента на землю. Тут всё просто, либо он понимает что есть объективные проблемы, но есть и Исполнитель в нашем лице, который их решит, либо клиент ищет кого-то ещё, а мы берёмся за следующий проект.
Если у вас есть решение на базе supervisord — поделитесь. Напишите в чём плюсы, в чём минусы. Это всегда интересно.
Особенно тревожный признак — когда клиент уверенно говорит что ему необходимо показывать на сайте остатки. В 95% случаев это означает, что нас ожидает период ожидания пока клиент не проведёт качественную, полную инвентаризацию.
Если клиент отказывается от услуг моего специалиста, и сообщает, что у него есть свой штатный программист, то я принимаю решение о работе над проектом только после личного контакта с его программистом.
Если программиста прячут, если контакта с ним нет, если стрелка его ЧСВ пробила приборную панель, то просто идём дальше. Потому что примеры автора топика уже оставили глубокий кровоточащий экспиренс в моей нервной системе. Такие заморочки практически ни когда на бывают оплачены адекватно. а опыт таких ситуаций ценен только одним — получением навыков избегать их повторения.
А вообще, я в таких проектах сразу довожу до клиента, что мы не просто решаем задачу создать ему каталог. Задача намного шире. В результате проведённых работ мы так или иначе будем вынуждены привести в порядок его учётную систему.
Два статических JSON файла. Один содержит ленту событий отслеживаемую клиентом, второй является хранилищем unix timestamp вида {«fresh»:1328202452}. Клиент опрашивает простым полингом файл с таймстампом, и при его изменении запрашивал основной файл. Вся прелесть этого решения дополняется nginx-ом, который эту статику весьма бодренько отдает. Операции с БД происходят только в момент записи новых данных. В случаях когда данные в БД поступают намного реже чем читаются, данный метод работает наиболее эффективно.