Создание плагинов для XenForo

Помогу с разработкой плагина для Xenforo.

Кому интересно, пишите.

 

Интересует, отписал в личку.

 

В каким пределах расценки?

 

зависит от сложности. нов принцепе договаривемся

 

Категорически не рекомендую работать с NIc.

Был заказан плагин, с выводом результатов работы нескольких формул. Такими как подсчет дней некурения, кол-во выкуренных сигарет, литража паров никотина поступивших в легкие и тд. В общем все в духе (дата отказа от курения - лет курения) * цену пачки сигарет и т.д. Детский сад короче. Все данных выводились в профиле пользователя. Для вывода информации для всего форума, генерировалась отдельная страница.

Все данные хранятся в дополнительных полях пользователей: Не курю с (дата формата дд.мм.гггг), Лет курения, Средняя цена пачки сигарет, Кол-во выкуриваемых сигарет. Вывод данных должен был осуществляться как для конкретного пользователя, так и для форума в целом (всех пользователей заполнивших соответствующие поля).

При этом, за десяток версий плагина, ни разу, повторяюсь ни разу, результаты работы не были получены со 100% точностью. Погрешности доходили и доходят, вплоть до нескольких десятков/сотен/ тысяч, а то и миллионов.

Работы с датами уровня

PHP:

$days * 365

А как-же високосные года?

Или уровня

Или уровня

Должно быть 439. Это в последней версии плагина.

Примеров множество.

Самый смех начался при выводе общей информации. Тобишь для всех пользователей форума, их около 2500. Страница выводившая эту информацию, выдавала в дебаге потрясающие значения

Девять тысяч запросов! Все хорошо, но даже при таких показателях, результаты вычислений были неверны. Мне в голову не приходит, каким образом можно для вывода вот этой информации (см. скрин), получить подобные цифры. И это при озвученных 12 годах опыта программирования.



На скрине результаты работы общего счетчика некурения.

При этом, я был обвинен в том, что все проблемы возникли из-за того, что я настоял на хранении данных 4-х полей в системных таблицах дополнительных полей xenforo, где им собственно и место, а не предложенной изначальной версии с отдельной таблицей.

Можно долго писать, например о дубляжах расчетов, полнейшее отсутствии комментов(хотя просил об этом), постоянному попреканию меня в том что использовались системные таблицы, в том, что я нифига не в теме, и т.д. Но время жалко.

Ошибка с моей стороны в том, что я дал очень слабое ТЗ, и дал кусково, понадеялся на простоту реализации, так как мне нужна была только заготовка, лениво было копать фреймворк, допилил бы сам.

Манибек ТС делать не хочет. Говорит что все ок. Доводить плагин до ума тоже, да и я уже не хочу, прошло практически две недели, а в итоге нифига не сделано.

Для желающих могу выложить образцы кода, логи разговоров и т.д.


Его реквизиты:
ICQ 315412
Kolya Bazhukov (Бажуков Николай Александрович)
Skype: nicb.home
Украина.
WMID: 258196634268
Один из сайтов: nickitos.com
http://www.free-lance.ru/users/nicb/

 

Покажите код, интересно глянуть.

 

Нет проблем. Тут куча версий. Последняя называется SmokingCounter_with_const, одна из первых SmokingCounterFirstVersion. Какая конкретно генерит 9xxx запросов, не вспомню.

 

Ну так что Вы хотите, если в одной функции делается 4 (!) запроса подряд к одной и той же таблице по одному и тому же ключу? Это первое, что бросилось в глаза. Ну и подсчет дней между датами в виде * 365... Да, это далеко от совершенства
Ну просто человек малоопытный. Такие ошибки, думаю, со временем он перестанет совершать.

Чуть не забыл. Использование пользовательских полей в задачах подсчета тотальных значений по всем пользователям в принципе ресурсоемко. Уж так они сделаны. По идее лучше использовать вообще свою таблицу, связанную отношением многие к одному. Но тогда придется писать свой интерфейс. Сложнее, но будет работать намного шустрее.

 

Судя по тому, что все ошибки кодинга были свалены на меня, это событие откладывается на неопределенное время.

Да понятное дело. Но это не причина для хранения значений основных дополнительных полей в отдельной таблице, когда для этого есть стандартные средства. Особенно на фоне того, что эти значения будут использоваться еще в серии плагинов. Какой мне смысл иметь привязку к сторонней разработке?

Впрочем ТС уже поступало предложение сделать общую выборку по дополнительным полям, с использованием кеша и обработкой например раз в сутки, коли он по другому не может, но и это предложение он доблестно проигнорил.

Вообще зла не хватает. Мало того, что нифига не сделано, так еще и время на него потратил с деньгами и нервами.

 

Просто считайте это венчурным инвестированием и конкретно эту сделку неудачной. Бизнес - есть бизнес

Очень спорное утверждение. Так как в зависимости от постановщика задачи, проектировщика и кодера, можно сделать и так и эдак. И везде будут свои плюсы со своими минусами. В Вашем случае можно делать кроном, конечно же. Но лично я не люблю крон по причине костыля. Если система не в состоянии штатно работать с данными в реальном режиме времени, то любые костыли в виде крона - это не более, чем костыли. Крон незаменим для тех ситуаций, когда нужно подчищать базу, делать рассылку и т.д., но не для обработки итоговых значений. ИМХО.