Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×
  • Как PM не нафакапить на новом проекте

    Абсолютно согласен.

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

    Підтримав: Galina Ryzhenko
  • Как PM не нафакапить на новом проекте

    Если команды большие то уже наверное я бы искал варианты разделить свою роль.

    Уже хотелось бы отдельно ba и может даже не один, уже можно лид qa выводить и выделять отдельную integration team (по типу integration team в nexus) чтобы вопросы технического анализа шли с опережением и со стабильно равномерной проработкой задач.

    Задачи по др, приездам и всему такому ещё можно делегировать hr и travel manager если такие предусмотрены.

    Правда комментарий немного дальше чем тема статьи.

  • Как PM не нафакапить на новом проекте

    В моем представлении работу менеджера можно разделить на условно администрирование (операционное управление проектом и его связями с внешним миром относительно проекта) и управление производством (процессы разработки, часто vision sharing, ba, часто части роли po).

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

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

    Підтримав: Vic
  • Как PM не нафакапить на новом проекте

  • Как PM не нафакапить на новом проекте

    У меня девопсы хорошо справляются с
    — описание инфраструктуры и ее использования
    — описания архитектуры (если еще не записал никто)
    — администрирование проекта (хотя часто может и qa)
    И в таком духе.

  • 14 типов менеджеров, которые бесят разработчиков

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

    Підтримав: Iryna Karpenko
  • Ищу специалиста по оптимизации MySQL

    Вот прямо так взять и выдать ссылку на статью затрудняюсь.

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

    Тестировал.
    Если просто сделать в цикле короткие select и короткие update много раз — все чтение с изменяемой таблицы приостанавливается, т.к. пока идут короткие селекты большие не успевают отработать.

    Пришел к выводу, короткие апдейты часто — не плохо, как и селекты.
    Плохо чередование много раз.

  • Ищу специалиста по оптимизации MySQL

    Не согласен. Не получается так.
    Лок на строку все равно не даст сделать select ... where

  • Ищу специалиста по оптимизации MySQL

    В MySQL основная проблема с запросами типа INSERT/DELETE/UPDATE в том, что при сколь угодно коротком запросе происходит блокировка всей таблицы. А это в свою очередь означает, что пока будет выполняться любой из этих запросов никакие другие происходить не будут.
    В целом, если запросов такого плана мало и они происходят не очень часто, то проблема с конкурентным доступом в таблицы легко решается с LOW PRIORITY.
    В таком случае все INSERT/DELETE/UPDATE будут дожидаться, пока выполнятся все запросы типа SELECT и потом будут выполняться сами, а если в очереди появится другой SELECT пока INSERT/DELETE/UPDATE ждет, то он тоже пойдет на конвеер. Тут можно ориентироваться на продолжительность самого длинного и среднего запроса в БД. Как правило, максимальная задержка INSERT/DELETE/UPDATE может составлять около 1-2 секунд.

    Однако надо учитывать один существенный момент:
    Если у Вас по каким-либо причинам происходит чередование SELECT и INSERT/DELETE/UPDATE, то никакие LOW PRIORITY Вас не спасут, очередь будет очень быстро заполняться из череды коротких запросов, а все остальное будет ожидать. На фронте это, как правило приводит к тому, что сайт долго генерирует страничку, т.к. сравнительно тяжелые пользовательские запросы постоянно стоят в очереди, дожидаясь снятия блокировки таблиц. А при коротком снятии блокировки их выполнение не успевает завершиться, и запрос снова попадает в очередь на ожидание.

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

    В случае, если — же вопрос стоит таким образом, что переход не предусматривается — тут на мой взгляд вариант только один — избегать чередования запросов типа SELECT и INSERT/DELETE/UPDATE.

    Относительно оптимизации СУБД
    По моей практике оптимизация СУБД в MySQL дело не сложное. Работы по оптимизации надо вести под нагрузкой. Идеально — когда нагрузка растет по мере роста посещаемости сайта.
    А все потому, что Вам будет понятно поведение СУБД только тогда, когда начнут формироваться очереди из запросов и их можно будет спрофилировать с тем, чтобы далее уже настраивать и оптимизировать.
    А на стадии разработки оптимизация СУБД есть оптимизация PHP кода и запросов.