Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (1)

Наибольший вклад в теги

Все теги (24)

Лучшие ответы пользователя

Все ответы (21)
  • Синхронизация MySQL запросов

    papahoolio
    @papahoolio
    Миграции.

    Идея миграций - вынести создание и изменение структуры бд в программный код. Одно изменение - одна миграция. Миграции имеют порядковый номер и соответственно выполняются друг за другом согласно порядковому номеру, где-то в системе всегда хранится номер миграции, которая была применена последней.

    Главное в миграциях, что после того, как она попала в репозитарий проекта, она изменяться уже не должна! Если нужно отменить изменения уже опубликованной миграции, пишется новая, отменяющая/исправляющая старую.

    Разработчики должны изменения структуры/наполнение бд делать только миграциями.

    Опять же для CodeReview миграции просто отличный инструмент.

    Для PHP
    Например в Yii:
    www.yiiframework.com/doc/guide/1.1/ru/database.mig...

    Как отдельно решение
    https://github.com/ruckus/ruckusing-migrations

    Для Python:
    https://pypi.python.org/pypi/alembic

    bash:
    https://github.com/dwb/dogfish/blob/master/dogfish
    Ответ написан
  • Хэширование (md5, sha2, whirlpool)?

    papahoolio
    @papahoolio
    Потому что md5($row['sha2'].'1') и md5($sha2).'1' разные вещи.

    Хеш-функция от разных строк даст разные хеш-суммы (ну кроме коллизий, но мы же не их ищем :)). В твоем случае последний md5 считается от разных строк. Почему? Ответ выше :)

    Замени $hash = md5(md5($whirlpool).md5($sha2).'1');
    на $hash = md5(md5($whirlpool).md5($sha2.'1')); и будет равенство.
    Ответ написан
  • Отправка сообщений через ZMQ

    papahoolio
    @papahoolio
    Второй скрипт создает сервер ØMQ на 5555 порту. Логично, что если этот скрипт умрет, то и сервера на 5555 не будет. Поэтому надо чтобы второй скрипт работал непрерывно.

    Первый скрипт открывает соединение с сервером ØMQ (клиент) и отправляет сообщение. Надо ли ему дальше жить? Судя по коду нет - он единождый отправил и свою работу выполнил. А если не по коду - who knows.
    Ответ написан
  • Macbook Pro 13 retina vs non-retina?

    papahoolio
    @papahoolio
    Братюнь, ты для себя просто определи, что тебе важно.

    Если ты часто таскаешь с собой, то тут надо крепко подумать об Air, бонусом будет чуть большая жизнь на батарейке

    Если важна бекенд разработка, то возьми не ретину и сразу докупи RAM и SSD, на оставшиеся 20к, потому как с 4Гб и медленным диском удовольствие от работы то еще, тем более Java.

    Если важна именно ретина, то сам понимаешь - бери. Но на 13" это сомнительное удовольствие, все же размер экранчика для глаз не очень комфортный. У меня была прошка обычная 13", работал в основном с внешним монитором, так как на экране ноута места не хватало.

    А так да, ретина это офигенно, но на 15", мне очень нравится =)
    Ответ написан
  • Много параметров у модели: сериализация или отдельная таблица?

    papahoolio
    @papahoolio
    Похоже, что при описании проблемы упущен важный момент, а как эти поля будут использоваться. Нужны ли будут данные из них всегда или только в определенных случаях?

    Давай посмотрим плюсы и минусы решений. Ну как я их вижу.
    Для варианта номер один.
    Плюсы:
    - со стороны PHP легко будет расширить AR
    Минусы:
    - unserialize медлено, есть конечно json и igbinary, но это все равно время
    - если полей "будет становиться всё больше", то в MySQL сериализованые данные нужно будет хранить в TEXT/BINARY поле, если мы говорим о стандартных ENGINE MySQL, то при выборке такие поля в память не загружаются, а читаются с диска, ну ты понимаешь, что дисковые I/O операции дорогие (в случае с InnoDB там может быть лучше ситуация)
    - если у нас случай, когда данные из "неизвестных" полей нам нужны редко, то при таком подходе, либо надо будет рисовать workaround в AR чтобы эти поля не тащить, либо будут данные постоянно пересылаться м/у БД и PHP, плюс в памяти PHP висеть
    - если база разрастется и нужно будет вытащить "неизвестное" поле в поиск/фильтрацию, изменение схемы таблицы потребует времени, вытаскивание данных из сериализованного поля и заполнение нового поля - потребует времени, построение индекса по новому полю - потребует времени. Много данных - много времени, времени простоя сервиса.

    Для варианта два.
    Плюсы:
    - если размер данных в полях лимитирован и залезает в тип VARCHAR, решаем проблему номер два первого способа
    - масштабируемо
    - внедрение поиска/фильтра по полю не повлечет переделывания структуры таблиц
    Минусы:
    - если данные нужны всегда, получится JOIN,если полей с данными будет много, то JOIN будет медленным. Если тип у полей будет TEXT... ну ты понял :)
    - проблему один можно решить кешированием, но реализация на PHP в рамках AR уже станет не самой простой задачей
    - да вообще в рамках AR Yii реализация такого подхода с lazy loading потребует нормального такого понимания, как AR в Yii устроен и где его надо менять, чтобы всем было хорошо

    Правильного варианта, как ты понимаешь нет, нужно взвесить все "за" и "против", понять насколько имеет смысл делать "круто" сейчас и тратить время или можно залезть в technical debt, но быстро запуститься уже завтра.
    Ответ написан