>>1097590

Судя по описанию здесь, надо заморочиться: https://bugs.php.net/bugs-generating-backtrace.php

- нужно скомпилировать отладочную версию PHP (без нее дамп сделать возможно, но в нем не будет имен функций, а только адреса). При большом желании ее можно скомпилировать не имея прав рута, но это конечно займет время. Также, придется компилировать opcache.
- могут понадобиться права рута, чтобы включить в системе core dump (если их нет, можно запустить веб-сервер из-под gdb как описано там, gdb должен быть установлен, при большом желании это можно сделать без прав рута)
- нужно запустить веб-сервер из командной строки (чтобы он запустился с настроенными через ulimit параметрами)

То есть нужно либо включить коредампы (может они даже уже включены, можно проверить через cat /proc/sys/kernel/core_pattern и ulimit -a ) либо запускать сервер из-под gdb (в однопоточном режиме). Второе наверно даже удобнее, но может быть баг в однопоточном режиме не проявится.

core dump - это дамп памяти упавшего процесса, из которого можно получить место, где произошла ошибка. Более того, если у тебя отладочная версия PHP, то ты можешь просматривать значения сишных переменных в дампе и выяснить в каком состоянии был интепретатор, какую PHP команду он выполнял и тд.

При этом надо помнить, что в core dump могут сохраниться куски PHP кода и данных (значения переменных), которые он обрабатывал.

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

Также, я еще кое-что придумал. Ты можешь попробовать запускать код без участия Апача (но с теми же настройками php.ini), используя встроенный в PHP веб-сервер ( http://php.net/manual/ru/features.commandline.webserver.php ). Его можно запустить даже без прав рута, если, есть доступ к командной строке. С помощью него ты можешь проверить: связано ли появление бага с Апачом или нет.

Разумеется, ты можешь также скопилировать отладочную версию PHP у себя на компьютере (если у тебя линукс или виртуальная машина с ним), главное взять ту же самую версию PHP и расширений (версию и параметры, с которыми был собран PHP, можно увидеть в phpinfo()). Это удобнее в том плане, что ты имеешь там все нужные права. Если ты раньше ничего не собирал, то это минимум несколько часов (а может и дней), так как будут возникать ошибки от того, что не хватает какой-то библиотеки или неверно прописан какой-то путь и ты будешь искать их причину.

>>1087406

Ой, пост пропустил. Потому я обычно и прошу напомнить о себе, потому что в треде на 900 постов можно что-то и упустить.

>>>+offset + +1

>>Немного странное место. Не многовато ли знаков "плюс"?

> Что поделать если js при сложении не преобразует данные в число? Приходиться делать это самому.

Ну это уже вопрос к твоему коду в backend, почему он числа в виде строк возвращает. А так, надо хотя бы скобки ставить для понятности: (+offset) + 1

>>Также, мне кажется, что у тебя в контроллере находится код, относящийся ко view: вызовы jQuery вроде if ($(that.view.moremessages).length) стоило бы перенести во view и писать вместо этого if (that.view.hasMoreMessagesButton()), а еще лучше - if (this.canShowMoreMessages()), так как это довольно коряво, проверять наличие новых сообщений по наличию кнопки на экране. Должно ведь быть наоборот - модель/viewModel сама знает, есть ли новые сообщения.

> Всегда нужно пользоваться только высстананвленными наружу методами, даже если код займет одну строку?

Тут скорее идея в том, что мы изолируем всю работу с DOM в один класс. Это ведь один из принципов ООП - single responsibility. И потому мы должны писать

view.showMessageCount(1);

а не

view.messageCountDiv.text(1);

Видишь разницу между 2 вариантами? Она в наличии/отсутствии инкапсуляции работы с DOM внутри view. Ну и если ты, например, захочешь сделать анимацию при изменении числа, в первом варианте это будет проще. Также, в первом случае код чуть понятнее, на мой взгляд.

Можно конечно не делать инкапсуляцию, но тогда возникает вопрос, а зачем вообще нужен view? Не проще его объединить с контроллером? Такой вариант тоже возможен.

Да, может показаться, что это раздувает код, но это потому, что ты пишешь все руками, не используешь библиотеки для data-binding (knockout, angular, react, vue и тд), которые решают проблему избавления от ручного обновления DOM.

>>Должно ведь быть наоборот - модель/viewModel сама знает, есть ли новые сообщения.

> Должно быть свойство модели/viewModel, например this.canShowMoreMessages = true/false?

Не знаю, зависит от реализации. Но вообще обычно данные хранятся/берутся из модели и передаются во вью для отображения. Ну например, можно возвращать это свойство вместе с результатами запроса к АПИ:

backend.getMessages(offset) -> [messages, hasMoreMessages]

И просто хранить в переменной. Можно хранить в свойстве контроллера. В переменной удобнее тем, что у нее ограничена область видимости.

Также, может быть, у тебя есть модель, представляющая хранилище сообщений. И тогда она может ответить на вопрос, есть ли еще:

var hasMore = messageList.hasMoreMessages(offset);

Но проверять наличие сообщений по наличию кнопки в DOM - это не соответствует MVC. И это имеет недостатки, при изменении этой кнопки придется менять код прокрутки, который, казалось бы, с ней никак не связан. Легко забыть поменять и создать баг. Поверь, тот, кто обнаружит этот баг, будет тебя не лучшими словами вспоминать.

Я там еще увидел, что ты решил пойти дальше и переменные начать хранить в DOM:

> var datawith = $('a', that.view.moreMessages).attr('data-with');

А что мешает хранить это в переменной?

Тот подход, который ты использовал - хранить данные в атрибутах, он вообще допустим. Ну например, мы могли бы сделать такой HTML-код для карточки отеля:

<div class="hotel-card" data-stars="3" data-city="London" data-price="100"></div>

Более того, давно уже ведутся разговоры по возможности добавления кастомных тегов, чтобы писать <hotel-card stars="3" city="London"></hotel-card>. Например, такое есть в Polymer.js, для этого добавили Shadow DOM. Такой синтаксис используют в Реакте. Почему нет? Вполне соответствует идее семантической (смысловой) разметки.

Но в таком случае обычно "карточка отеля" - это отдельный компонент. Где-то есть скрипт, который читает эти атрибуты и обрабатывает их, есть шаблон и тд. А у тебя не так, у тебя ведь кнопка не оформлена как отдельный компонент. Ты просто используешь DOM атрибуты как поля объекта или переменные, и возникает вопрос - а что мешает данные сразу и хранить в полях или переменных?

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

>>Из-за того, что ты в контроллере смешиваешь код view, код установки обработчиков, асинхронные вызовы, все это выглядит сложно и запутанно.

> Разве контроллер не должен "дирижировать" всем этим?

Я не помню, что я имел в виду, но думаю, я хотел сказать о 1) разделении ответственности (например, только вью работает с DOM напрямую) и 2) о преобразовании больших функций с кучей колллбеков (callback hell). Может их надо на части разбить, может их надо писать не вложенно, а последовательно.

Про callback hell, это когда пишут так:

$(...).click(function (e) {
$.ajax({
url: ...,
onsuccess: function (result) {
setTimeout(function () {
$(...).click(function () {
...
});
});
}
})
});

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

Я вот сейчас открыл твой код - и обнаружил там те самые 2 пробела. Как в воду глядел.

Вот это вот код не для человека:

https://github.com/someApprentice/chat/blob/master/public/js/conversation.js#L71

> that.backend.handleError(jqXHR, textStatus);

> }

> );

> }

> }

> }

> }.bind(this));

> };

Я не робот и я не могу в уме посчитать, к чему тут относится bind(this). 8 уровней вложенности! 3-4 хватило бы с лихвой.

Промисы позволяют победить это:

var result = doSmth();
result.catch(...);
result.then(function () {
...
}).then(function () {
...
});

Также, можно выносить код в функции:

$(btn).click(handleClick);
$(btn2).click(this.handleClick.bind(this));

Алсо, кто-то даже сделал сайт по теме http://callbackhell.com/

Или тут: https://github.com/someApprentice/chat/blob/master/public/js/conversation.js#L80 - функция на целых 60 строк. Пока я дойду до конца, я забуду, что было в начале.

И еще, ты-то может это знаешь, но я например не понимаю, за что отвечает каждый класс. Вот conversation.js - это контроллер области сообщений? Контроллер, отвечающий за переписку вообще? Стоит взять за правило писать перед классом, за что он отвечает и зачем нужен. Кроме самых очевидных случаев.

Огромные if можно превратить в маленькие, если поменять условие на противоположное.

if (!...) {
return;
}

Вот попробуем упростить это:

https://github.com/someApprentice/chat/blob/master/public/js/conversation.js#L31

> that.backend.getLastMessages(datawith, offset).then(function(data) {

> проверка, что URL не изменился

> отправка сообщений на расшифровку

> обновление DOM

Я бы сделал так. Все, связанное с расшифровкой, просто вынес бы в функцию. Использовал бы промисы для выполнения асинхронных операций последовательно:

var encryptedPromise = that.backend.getLastMessages(datawith, offset);
var decryptedPromise = encryptedPromise.then(this.decryptMessages.bind(this));
decryptedPromise.then(function (decrypted)) {
если (URL изменился) { выйти; }

this.appendMessages(decrypted);
this.showSomeButton(...);
...
};

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

Иногда ситуация бывает сложнее, чем я написал. Ну например, бекенд возвращает 2 значения, { encryptedMessages, haveMore }, и надо как-то передать haveMore в функцию вывода данных, пропустив этап расшифровки. Я не знаю правильного ответа, попробуем например что-нибудь написать:

var resultPr = that.backend.getLastMessages(datawith, offset);
var viewData = resultPr.then(function (lastMessages) {
var decryptedPr = that.decrypt(lastMessages.encryptedMessages);

// Добавляем haveMore в результат расшифровки
var decryptedAndHaveMorePr = decryptedPr.then(function (decrypted) {
return {
haveMore: lastMessages.haveMore,
decrypted: decrypted
};
});
return decryptedAndHaveMorePr;
});

viewData.then(function (decryptedAndHaveMore) {
// вывод сообщений
}, function () {
// вывод ошибок
});

Не знаю, читабельно ли вышло? Может, ты сможешь красивее записать? Асинхронный код, он такой, на await/async ( https://developer.mozilla.org/ru/docs/Web/JavaScript/Reference/Operators/await ) это бы наверно компактнее получилось:

var result = await that.backend.getLastMessages(datawith, offset);
var decrypted = await decryptMessages(result.encrypted);
view.showMessages(decrypted);
view.showMoreButton(result.haveMore);

>>Также, твой Crypter является по сути оберткой над openpgp, ничего от себя не добавляя. Непонятно, в чем смысл его существовани

> Вы выше делали замечание что нужно делать обёртку. Я запутан.

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

>>1097368

>Насчет данных с paypal - не знаю, скорее всего нет. Но думаю, они будут доступны для американской разведки.

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

>Авторское право © PayPal, 1999–2017 гг. Все права сохранены. Общество с ограниченной ответственностью Небанковская кредитная организация «ПэйПал РУ». Юридический адрес: Российская Федерация, 125047, Москва, ул. Бутырский Вал, д. 10. Деятельность осуществляется на основании лицензии Центрального банка России № 3517-К.

Но у российской разведки уже есть мои данные, так что волноваться не о чём.

>> Мне видеться использовать JSON-объект с свойствами каждого вложения.

>Скорее всего что-то такое и было.

Я думаю, вот можно было для какой-нибудь сущности иметь колонку temp с типом JSON и сохранять туда какие-нибудь второстепенные/временные/неважные данные. Можно былоо бы гибче обращаться с записями. Как вам идея?

>- кеширование - кеш снижает нагрузку на чтение из БД, при условии, что запросы повторяются, и что обновление данных происходит реже, чем чтение.

Можете посоветовать какой-нибудь софт/библеотеку для этого?

>> Как можно заранее построить схему, если со временём неизбежно придётся что-то менять, а данных слишком много?

>Вот ты думаешь, что проблема - это слишком много данных, а реальная проблема - это то, что у тебя слишком мало пользователей. Если у тебя будет очень много пользователей, то скорее всего и будет много денег для покупки серверов.

>

>А так, сохранять стоит все, что есть.

Нет, я имел ввиду что структура таблицы может поменяться и старые данные могут не соответствовать этой структуре.
К примеру, что-то не предусмотрели, например, понадобилось в список чатов добавить ещё время добавления пользователя в чат, но уже в созданных чатах есть добавленные пользователи и невозможно получить их время добавления.
Нужно заранее подготавливать "правильную" структуру, но такое было бы возможно если бы прогресс стоял на месте.

Но я только что понял, что такой вопрос нужно решать на стадии миграции.