• Как обращаться к api.telegram.org?

    bel_poprygun
    @bel_poprygun
    Директор в АйТиЭс
    Я использовал PHP-обёртку telegram-bot/api
    В нём поправил файл vendor/telegram-bot/api/src/BotApi.php:
    public function call($method, array $data = null)
        {
            $options = [
                CURLOPT_URL => $this->getUrl().'/'.$method,
                CURLOPT_PROXY, "socks5://LOGIN:PASSWD@IP:PORT",
                CURLOPT_SSL_VERIFYPEER => false,
                CURLOPT_RETURNTRANSFER => true,
                CURLOPT_POST => null,
                CURLOPT_POSTFIELDS => null,
            ];
            ...
    Ответ написан
  • Как подходить к решению нетривиальных задач?

    Привет.

    Всегда использую модель боли:

    1) Смотришь задачу
    2) Пытаешься её решить
    3) Понимаешь, что ты тупой идиот, который ничего не может.
    4) Поднимаешь в помощь гугл
    5) Поднимаешь в помощь литературу
    6) Спрашиваешь ребят на тему: "почему так, а не иначе".
    7) Выполняешь задание, осознавая, что ты тупой, раз на решение этой задачи тебе пришлось потратить столько времени.

    Повторить до бесконечности, и ты станешь профи.
    Ответ написан
  • Как запустить windows server 2003 на консольном Debian?

    @sazhyk
    KVM + virtmanager + xming - при работе с удаленным сервером из среды Windows
    При работе из среды Linux xming отпадает сам собой.
    В virtmanager'е вполне себе удобный мышекликательный интерфейс.
    Ну а потом обычным клиентом подключаемся к сарверу по протокулу RDP.
    Да, и я бы не стал устанавливать сервер Windows в одном месте, переносить и разворачивать его потом в другое. Не любит Windows такие финты. Да и настройки поболе будет. Но это имхо.
    Ответ написан
  • Насколько сложно изучить разработку для 1С бухгалтеру?

    ulrich-schnauss
    @ulrich-schnauss
    Системный администратор, веб-разработчик
    Не сложно. Есть только один автор, который понимает что пишет (т.к. является разработчиком 1С), это Радченко. Все начинают с его книг.
    Ответ написан
  • Как запустить windows server 2003 на консольном Debian?

    fox_12
    @fox_12
    Расставляю биты, управляю заряженными частицами
    Делал такое на VirtualBox в Headless режиме. Правда на CentOS без X-сервера, но суть та же.
    Особых сложностей не возникло. Полет нормальный.
    Ответ написан
  • Как запустить windows server 2003 на консольном Debian?

    landergate
    @landergate
    IT-шный jack-of-all-trades
    Да, можно запустить Windows Server на любой технологии виртуализации, что упомянул Андрей Буров.

    если поставить в другом месте и образ готовый перенсти на Debian и запустить в консоле, заработает ?

    Да, но учитывайте, что для подключения пользователя к виртуальной Windows Server, к ней должен оставаться доступ по сети. Либо Windows Server может иметь свой собственный публичный IP-адрес, настроенный на интерфейсе в режиме Bridge (у конкретного хостинга могут быть свои рекомендации/требования по этому поводу), либо через NAT, где в качестве шлюза выступит Debian, а на нём будет настроен Port Forwarding до RDP виртуального Windows Server.
    Ответ написан
  • Как запустить windows server 2003 на консольном Debian?

    BuriK666
    @BuriK666
    Компьютерный псих
    virtualbox, kvm, xen, qemu
    Всеми можно управлять из консоли (у virtualbox есть web-интерфейс)
    Ответ написан
  • Как читать файлы в несколько потоков в Linux?

    MetaDone
    @MetaDone
    Хорошо сформулированный вопрос - 50% решения
    наверно самый простой способ это gearman.info
    тем более если будете использовать php - то есть документация php.net/manual/ru/book.gearman.php
    выйдет примерно так:
    1. клиент раскидывает задачи воркерам - какие файлы им обрабатывать
    2. воркеры получают список файлов из очереди и конвертируют их
    2.1 если все вышло - шлют что задание выполнено (php.net/manual/ru/gearmanjob.sendcomplete.php)
    2.2 если не получилось - шлют что не вышло (php.net/manual/ru/gearmanjob.sendfail.php)
    по третьему вопросу - php.net/manual/ru/gearmanclient.setcompletecallback.php php.net/manual/ru/gearmanclient.setfailcallback.php - так можно будет на клиенте узнать сколько выполнено и провалено заданий
    Ответ написан
  • Какие современные веб-технологии нужно знать middle разработчику?

    miraage
    @miraage
    Старый прогер
    Ну-с, как минимум, Вы должны, как рыба в воде, понимать и применять то, что описано на этом сайте.

    www.phptherightway.com
    Ответ написан
  • Как вы пишите тестируемый код?

    @matperez
    Почитайте книжулю The Clean Architecture in PHP. Там и про архитектуру и про тесты есть.
    Ответ написан
  • Продвинутая литература по тестированию?

    @matperez
    Как не смешно звучит, сам я эти книжки не читал, но, когда собирал подобную же вашей коллекцию, заметил, что их во многих местах рекомендовали безотносительно языка:
    The-Art-Unit-Testing-examples
    xUnit-Test-Patterns-Refactoring-Code
    ActiveRecord нормально тестируется с помощью частичных моков. Даже запросы нормально тестируются, если их выносить в отдельный класс, а ActiveRecord::find() использовать только как фасад для получения инстанса нужно класса с запросами.
    П.С. Поделитесь потом что нашли и что реально оказалось полезным.
    П.П.С. А вот еще книжка хорошая The Clean Architecture in PHP. Она вроде бы не сложная, но очень хорошо описывает как можно IoC использовать, а это прямой путь к хорошим тестам.
    Ответ написан
  • Как вы пишите тестируемый код?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    соответственно при тестировании необходимо обернуть его в Mock

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

    Писать в каждой модели конструктор?

    Что вы понимаете под "модель"? Ваши бизнес-объекты? У них в конструкторе должно быть только то, что им нужно.

    а если источников будет много

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

    User::model()->prepareBuy(new Order, New Profile, $userId)


    Прочитайте эту строчку кода, и скажите что тут происходит, ибо я не могу этого понять.

    Ну и да, помимо внедрения зависимостей в конструктор, есть еще такая неплохая штука как double dispatch, когда нужные сервисы передаются как аргументы методов, которым они нужны. Так наш класс не зависит от непонятных вещей и таким образом мы все можем спокойно тестить.
    Ответ написан
  • Как вы пишите тестируемый код?

    alexey-m-ukolov
    @alexey-m-ukolov Куратор тега PHP
    Для решения этой проблемы и придумали Dependency Injection и IoC-контейнер.
    Ответ написан
  • Как вы тестируете статические методы?

    He11ion
    @He11ion
    PHP-monkey
    Зависит от Вашей архитектуры, я применяю класс-"обертку" с перегрузкой нужного метода (этим же трюком пользуюсь для изменения вызова функций класса-родителя)

    Как-то так:
    class A { // "родной" класс
    	static function static_call ()
    	{
    		echo 'static_call a';
    	}
    }
    
    class B extends A{ // "обертка" для тестирования
    	static function static_call ()
    	{
    		echo 'static_call b';
    	}
    }
    Ответ написан
  • Как вы тестируете статические методы?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Как вы тестируете статические методы?


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

    В вашем же вопросе вы интересуетесь как мокать статические методы. И тут ответ тоже никак:
    Please note that final, private and static methods cannot be stubbed or mocked. They are ignored by PHPUnit's test double functionality and retain their original behavior.


    Есть правда еще мокери всякие и т.д.
    Ответ написан
  • Как и в каких случаях использовать DI в Yii2?

    SamDark
    @SamDark
    Yii2 core team
    DI именно в вашем случае не при чём. Это способ реализации, а не сама идея. Идея состоит в том, что вам нужно реализовать принцип инверсии зависимостей. То есть начать работать с интерфейсами, а не с конкретными реализациями.

    Чтобы быть универсальным и переносимым, модуль не должен знать о моделях извне себя. Вместо этого он должен выражать свои требования в виде интерфейса, а внешние модели этот интерфейс должны реализовывать.

    Для вашего примера делаем в модуле Article делаем интерфейсы:

    interface ArticleInterface
    {
        public function getTitle();
        public function getAuthor();
    }
    
    interface ArticleAuthorInterface
    {
        public function getName();
        public function getID();
    }


    Далее в пределах модуля используем только интерфейсы, а не сами модели:

    public function renderArticle(ArticleInterface $article)
    {
        return $this->renderPartial('_article', [
             'author' => $article->getAuthor(), 
             'title' => $article->getTitle()
        ]);
    }


    Вне модуля нам придётся реализовать интерфейсы в моделях:

    class Article extends ActiveRecord implements ArticleInterface
    {
       // ...
    }
    Ответ написан
  • Что представляет собой тестирование ?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    Вообще вики можно для начала, а потом уже углубляться в литературу. Вот вам кратенькое описание, цель которого больше предоставить ключевые слова для поиска.

    Модульные, они же юнит тесты, предназначены для тестирования отдельных модулей/классов. Суть их в том, что мы тестируем поведение только одного класса за раз. Если класс ссылается на инстансы других классов - мы их мокаем. То есть подсовываем им фэйковый класс, который имеет тот же интерфейс, но внутри не реализациа методов, а проверка, вызывали ли метод, с каким аргументами, сколько раз вызывали и т.д. Так же методы мока могут возвращать стабы (заглушки), какие-то захардкоженные под какой-то кейс данные. То есть если мы пишем класс по работе с базой данных, сокет-сервер и т.д., нам стоит соединение с базой, сокеты и т.д. оборачивать в классы, что бы можно было потом подменить на моки это добро. Если у вас в юнит тестах идет реальная работа с файловой системой или что-либо в этом духе, то это уже попахивает интеграционными тестами. Подробнее можно почитать в документации к phpunit. Так же есть такая методология разработки как TDD, советую почитать "Экстримальное программирование" Кента Бэка в этом ключе.

    Сразу хочу отметить что юнит тесты это хорошо, но вот только рядовой разработчик на PHP редко пишет что-то, что стоит покрывать юнит тестами. Времени на их поддержку нужно не мало, а требования у заказчиков частенько меняются. В итоге тесты начинают комментить и толку от них становится ноль. А вот если вы пишите компонент/библиотеку, то тут юнит тесты обязательны (ну... не то что бы, но желательны). Так что я бы на вашем месте сконцентрировал внимание на первом этапе на интеграционных и приемочных тестах.

    Интеграционное тестирование - тестирование нескольких модулей в связке. То есть мы тестируем наш компонент или его самодостаточный кусок в реальных условиях. Если этот компонент для работы с файлами - разрешаем ему доступ к файлам. Если база данных - то даем реальное соединение с базой. А можем что-то и замокать. Это как говорится, зависит от задачи. Скажем обращение к сторонним апишкам стоит мокать и стабить. Главная цель этих тестов, удостовериться что модули вместе работают хорошо. Особенно важно это когда модули пишут разные люди.

    Функциональное тестирование - это тестирования всего приложения в сборе. Если это REST API, то у нас через curl дергаются реальные методы, отправляются более менее реальные запросы и валидируются ответы. Если web-страничка, то это UI тесты с силениумом/phantom.js/zombi.js или, если нам не нужно еще и js тестить, просто curl + какой виртуальный браузер на том же php. Вообще по хорошему функциональные тесты не допускают никаких моков и т.д. но опять же если очень хочется то можно (опять же обращение к сторонним сервисам, контроля за которыми у нас нету).

    Но реалии таковы, что UI тестами покрывать проект не слишком удобно. Вопервых UI может меняться, а поддерживать их так же нужно. Во вторых это скучно. В третьих тесты могут просто падать... вот взяли и упали. И потом начинается, так, тесты опять упали... что там упало? А, не страшно, можно релизить. Так же на больших проектах UI тесты отрабатывают долго, очень долго, некоторых их просто ночью гоняют. Толку от тестов при таком подходе не слишком много, ибо разработчику стоит знать о том что что-то сломалось как можно быстрее. А так он приходит, видит что тесты опять красные, чинит эти красные тесты, и запускает... ждет... проходит пол часа к примеру, и где-то в другом месте отвалилось... Короче сами понимаете.

    Приемочное тестирование - по сути те же функциональные тесты, но подаются в контексте фича-спеков. Если вы работали когда-нибудь с QA отделом, то возможно слышали про такие штуки как acceptance criteria. То есть это тот чек лист, который должен проверить тестировщик что бы удостовериться что все хорошо. На основе этого чек листа можно написать функциональные тесты. Так же есть инструменты вроде Cucumber/Behat, которые позволяют писать спецификации в виде стэпов. В этом случае спецификации для этих инструментов могут писать QA а вы просто имплементите для них степы. То есть уменьшается прослойка между "acceptance criteria" и готовыми к выполнению тестов. Более того, стэпы можно реюзать, комбинировать, масса стэпов есть готовых, вам же необходимо только предоставить стэпы подготвалливающие систему (загрузка/генерация фикстур и т.д.). Короче лепота и удобно. Но медленнее интеграционных, зато не такие жесткие как функциональные, за счет этого их проще поддерживать. QA пишут спеку, реализуем тесты под эту спеку, пишем код под тесты, тесты зеленые - функционал готов.

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

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

    Короче почитайте про TDD и ATDD (можно и BDD затронуть, но тут не только от программиста зависит, менеджеры, заказчик или продукт-оунер тоже должны быть вовлечены, по сути этот подход хорошо работает в рамках продукта какого-то, на фрилансе и в аутсорсе редко можно встретить) , Continious Integration и Continious Delivery.
    Ответ написан
  • Как починить GRUB (не видит windows 7 после форматирования диска с linux)?

    bestking5236
    @bestking5236
    постоянно устраиваю необычные проделки
    Скорее всего, у Вас UEFI/EFI. У меня такое было после установки линукса паралельно с Windows 7 на EFI. Grub просто не "подхватил" нужную запись.
    В линуксе сделайте в терминале, пот рутом:

    ~# update-grub
    ~# reboot

    Если не появился нужный пункт в списке систем, продолжаем. Выполните под рутом:

    ~# grub-probe --target=fs_uuid /boot/*/*/Microsoft/Boot/bootmgfw.efi
    выводом будет Ваш идентификатор диска с виндой - выпишем его на бумагу

    затем выполните (я использую vim, если не знакомы - любой другой консольный редактор:
    ~# vim /etc/grub.d/40_custom
    и в самый конец допишите, после всех комментариев с новой строки:

    menuentry "Windows x86_64 UEFI-GPT" {
    insmod part_gpt
    insmod fat
    search --fs-uuid --no-floppy --set=root ВАШ_ИДЕНТИФИКАТОР_С_БУМАГИ
    chainloader /EFI/Microsoft/Boot/bootmgfw.efi
    }


    После этого выполните от рута:
    ~# update-grub
    ~# reboot

    Profit!
    Ответ написан
  • Как обойти отсутствие транзакций в MongoDB?

    — передача денег от А к В с проверками и откатами;

    Просто не надо использовать mongodb для этого. Не получится. mongo написана для хранения не ценных данных, потери которых мало кого интересуют. Поэтому, например, mongo по-умолчанию сразу возвращает успех, не дожидаясь записи в базу.
    — покупка товара (уходит со склада и приходит пользователю в заказы, причем так, чтобы 2 пользователя не купили последний товар со склада, а владелец товара не успел изменить цену, пока пользователь покупал (условно говоря лок на товар))

    Это скорее всего можно сделать атомарными операциями. Но если надо, локи организуются с помощью поля «заблокирован до», уникального индекса на id товара и запросов вида
    upsert(«объект с установленным полем времени блокировки», «время блокировки меньше текущего времени»)
    Если лока еще нет, то он будет создан. Если лок есть но просрочен (захвативший его процесс упал), то запрос обновит такую запись. Если лок захвачен, то запрос попытается создать новый lock, но упадет из-за дубликата ключа в индексе.
    Ответ написан