• Как на PHP реализовать беспрерывное выполнение задачи?

    $file='/tmp/parser_status.lock';
    if(!flock($lock_file = fopen($file, 'w'), LOCK_EX | LOCK_NB))
      die("Already runninng\n");

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

    Костыль конечно, но работает уже несколько лет :)
    Ответ написан
    Комментировать
  • Что такое фикстуры и миграции?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Фикстуры - это по сути тестовые данные. Они нужны для unit-тестирования. Это могут быть как данные в базе, так и обычные файлы (обычно 2 варианта, до и после обработки так скажем). Каждый раз когда запускаются тесты, эти данные используются для установления начального состояния системы, что бы тесты всегда выполнялись предсказуемо.

    Для функционального тестирования (тестрирование контроллеров, интаграционных тестов) фикстуры не применяются, хотя суть там так же сходна. Если честно, то тут мнение расходится. Одни говорят что при функциональных тестах нельзя использовать даже моки, то есть система в процессе выполнения тестов полностью создает то состояние которое необходимо для других тестов. Например последовательное выполнение тестов на добавление статьи и ее просмотр. Другие же предпочитают для каждого тесткейса выставлять состояние с нуля. По сути это схоже с использованием фикстур, но реализация различается. У вас есть некое api для заполнения данными (скажем метод добавляющий пользователя), и перед выполнением тест-кейса происходит ресет данных и заполнение их новыми. Плюсы так же есть - можно распаралелить выполнение тестов. (но не верьте мне на слово)

    Миграции - механизм организации версионности структуры проекта. Вы можете написать миграцию для изменения местоположения статики (картинки, поменять ссылки в базе и т.д.), или же у вас добавляется новая таблица/поле. Обычно дополняется обратной миграцией, которая восстанавливает исходную структуру. Обязательно для работы в команде или при частом изменении организации данных в проекте, вообще я бы посоветовал использовать их всегда.
    Ответ написан
    Комментировать
  • Как правильно использовать исключения?

    Тут достаточно просто все.
    Исключения помогают проскочить участок кода при выполнении определенных условий.
    Причем, при коде без вызовов функций - всегда можно заменить на if/else, но код будет многовложенным (один if в другом). Но такой код естественно давно никто не пишет.

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

    Идея же исключений такая:
    1. У нас есть алгоритм, который должен работать по заданной схеме. Мы нигде на уровне выше не проверяем корректность возвращаемых значений или правильность выполнения уровня ниже - он должен выполниться правильно или не выполниться. Это условие рождается из понимания инкапсуляции - каждый отвечает за свой кусок кода.
    2. Если в какой момент момент, метод (кусок кода), отвечающий за определенную функциональность понимает, что не может выполнить назначенную ему операцию - он сообщает об этом на уровень выше.
    3. Уровень выше может обработать исключительную ситуацию, либо (если не знает как) - передать исключение еще уровнем выше по стеку вызовов.

    Т.е. резюмирую: у нас есть код, который должен в 90% случаев обрабатываться по одному алгоритму и в 10% случаях могут возникать ситуации, когда этот алгоритм в одной конкретной части кода - пойдет по другому сценарию.
    Т.е. ваша задача писать код именно таким образом, чтобы исключения были лишь подстраховкой, а не частью основного алгоритма.

    Интересный момент реализации исключений в lisp: там можно выполнить код вызвавший исключение повторно (например попытаться подключиться к базе второй раз средствами самого исключения).
    Ответ написан
    Комментировать
  • Как правильно использовать исключения?

    if-elsе (switch) используется в случаях-
    "если не так, то попробуем с другой стороны",
    то есть, это выбор вариантов исполнения.
    а exception-
    "если не так, то никак (потому, что ....)",
    то есть остановка исполнения, и старт каких либо заключительных действий (например, записать ошибку в лог и отправить пользователю красивую картинку/заглушку).
    таким образом, "if" - это штатный режим, а а exception- аварийный
    Ответ написан
    1 комментарий
  • Как правильно считать часы при «почасовой оплате»?

    vsespb
    @vsespb
    Всё ниже написанное — имхо, не подкреплённое ничем.

    обучение, пассивное обдумывание, совещания, обсуждения и пр

    это всё трекать.

    Даже посещение туалета входит в оплачиваемое время

    Не относящиеся дела к работе не нужно трэкать. Туалет можно только потому-что он занимает 5 минут.

    Так же, если по инициативе/вине заказчика, вас часто отрывают от ваших личных дел (не относящихся к работе) и заставляют переключаться на работу, то можно добавлять 10-15 мин «за переключение»,

    Лично я корректирую время на свое усмотрение, особенно если у меня уже есть готовое решение (ну или большая часть нужного функционала)

    Имхо, это не правильно (не честно).

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

    Если же вы, благодаря тому, что у вас было готовое решение, потратили 1 час вместо 4, пишите один.

    Заказчик покупает вас со всеми вашими скиллами, способностями, и если где-то вы потратили много времени — это вина заказчика (он дал вам такое задание). Если вы где-то сэкономили время — это не ваша заслуга — он вас «купил» таким какой вы есть.

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

    Если сопоставить с офисным работником, то, согласно опросам, активная работа в лучшем случае занимает 4 часа в день, а чаще 2-3 часа.


    Сопоставлять рейт и часы офисного работника и фрилансера напрямую нельзя.

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

    Он определённые процент времени бездельничает в офисе, общается с коллегами.

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

    Я лично считаю, что час фрилансера, сравненный с часом офисного работника (посчитанного как 22*8) должен стоить дороже. Это нужно объяснить заказчику, если он не работал с фрилансерами ранее.
    Ответ написан
    1 комментарий
  • Доменная зона .io — что я пропустил?

    vosi
    @vosi
    input/output?
    это ж как-бы основа всех основ )))
    Ответ написан
    5 комментариев
  • Статьи про кэширование в PHP

    Gibbzy
    @Gibbzy
    ну там несколько вообщем то своств у этого кэширования
    куда скэшировать
    -В файлики
    -В память
    -В базу данных (бывает и такое)
    -Куда то еще (есть такие выдумки огоогоо)

    Что скэшировать
    — Результаты выполнения запросов (Что то в моделях)
    — Готовый html (Прям вместе с запросами с явскриптом и со всем всем всем)
    — Вообще кэшировать можно все что угодно любой объект который поддается сериализации

    Остается только разобратся в каких случаях какую комбинацию стоит применять.

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

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

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

    Ключ можно составлять по разным принципам начиная от id какого ли бо объекта или id + еще id + еще id
    или вообще можно использовать хэш от sql запроса.

    Прочитайте про memcache, если вам нужно что то более мелкоколиберное попробуйте APC, ну и вообще все можно в файликах хранить на всякий случай. С файликами аккуратнее у меня однажды была история когда кэш занял все дисковое пространство, в результате моей ошибки.

    Вообщем такие вот дела, ничего сложного, удачи!
    Ответ написан
    Комментировать