Сообщения

Битрикс: получить путь файла

В битриксе так устроено, что каждый загружаемый файл (картинка, документ или что-угодно ещё) сохраняется и на диске, и в базе данных (основные параметры файла). В базе данных параметры файлов хранятся в таблице b_file . Если в инфоблоке загрузить картинку, то у элемента инфоблока в поле картинки сохранится только идентификатор - отсылка на запись в таблице b_file . При выборке данных через CIBlockElement::GetList() и Fetch() от картинки будет получен только идентификатор. Чтобы идентификатор превратить в путь к файлу картинки, нужно, например, применить метод CFile::GetPath() и передать в него этот идентификатор файла. Этот стандартный битриксовый метод внутри делает много всякого. В том числе, кеширование результата. Далеко не всегда это кеширование полезно, на мой взгляд. Очень часто файлы получаем внутри компонентов, которые сами имеют кеширование. Или при обработке большого числа файлов, выгодно один раз из кеша достать сразу всю пачку, чем каждый файл из отдельного маленького к

Оплата PhpStorm в России

Изображение
PhpStorm в РФ всё Несколько лет я был счастливым обладателем лицензии на PhpStorm. Продлял лицензию на свой рабочий инструмент и зарабатывал благодаря этому. С 2022 года в России пропала возможность оплатить лицензию. JetBrains продлили действие лицензий на территории РФ. Но вот и срок продления вышел. В итоге, для российских разработчиков официально остался только вариант откатиться на последнюю доступную в РФ версию - PhpStorm 2022.3. Причём, если переключить страну в личном кабинете JetBrains, то последняя доступная версия оказывается 2021.3. Вот такой командой можно откатиться к последней доступной версии в РФ, если ранее приобреталась лицензия (для Linux при установке через snap): sudo snap refresh phpstorm --channel=2022.3/stable --classic; Чтобы пакет не пытался обновиться, можно зафиксировать его: sudo snap refresh --hold phpstorm Например, через snap был установлен PhpStorm у меня на Kubuntu. Покупка продления из РФ Далее описание серой зоны, как можно всё-таки купить ли

Монтирование NFS

Смонтировать удалённую файловую систему можно несколькими разными вариантами. Сейчас опишу, как я это сделал на свежеустановленной KUbuntu. Во-первых, чтобы не выходила ошибка вида: mount: /mnt/storage/public: bad option; for several filesystems (e.g. nfs, cifs) you might need a /sbin/mount.<type> helper program. Нужно установить пакет, в котором будет библиотека для поддержки клиентского функционала NFS: sudo apt-get install nfs-common Далее мне нужно было один из каталогов моего файлового хранилища подключать в мой локальный каталог (я его предварительно создал) - /mnt/storage/public. Ранее я это делал через /etc/fstab записью вида: 192.168.1.245:/mnt/public /mnt/storage/public nfs nofail,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10 0 0 Сейчас по совету статьи "Автомонтирование файловых систем с systemd" решил сделать то же самое через systemd. Создал два файла: sudo nano /etc/systemd/system/mnt-storage-public.mount

PHP: значения по-умолчанию и типизация

Рассмотрим примеры, когда значения по-умолчанию в комбинации с указанием типов входных и выходных параметров функции могут ввести в заблуждение. Для начала рассмотрим такой сценарий: требуется разработать функцию, которая будет возвращать всегда целочисленное значение, а на вход принимает один параметр - тоже целочисленный. Заготовка: <?php class Product {     /**      * @param int $productId      *      * @return int      */     public function getStrangeProduct(int $productId): int     {         return $productId;     } } $obProduct = new Product(); При таком раскладе совершенно очевидно, что вызов var_dump($obProduct->getStrangeProduct(0)); вернёт целочисленное значение 0: /mnt/projects/sites/server.local/www/test-functions.php:16:int 0 Теперь представим, что ТЗ изменилось. Теперь нужно, чтобы функция имела значение по-умолчанию для входного параметра, когда функция вызывается без указания параметра. Так функция примет вид:     /**      * @param int|null $productId   

Запуск приложений ARM на x86 virtual Android

Изображение
Задача: запустить любимую игрушку или полезное приложение Android на компьютере под управлением linux. Первый шаг - это запустить хоть сам голый Android на компьютере внутри базовой операционной системы.Для этой цели есть несколько вариантов решения. Можно использовать стандартный эмулятор Android для разработчиков от Google, - запустить любую версию Android. Можно использовать Anbox с его Android 7.1. Фишка Anbox в том, что будет максимально задействовано родное железо без лишних слоёв эмуляции. Третий вариант, который я тут приведу - Genymotion - платный проект виртуализации, в котором можно получить бесплатную лицензию для домашнего использования. В общем, выбрать есть из чего. Где взять программу для установки Какой бы проект вы не установили, потребуется найти установочный пакет интересуемого приложения или же установить менеджер приложений (самый популярный вариант - Google App и Google Play services в придачу к нему). Начнём с самого простого случая. Вариантов будет несколько

Postman: nginx secure link

Изображение
В предыдущей статье рассматривался вариант защищённых ссылок, которые предоставляет модуль ngx_http_secure_link_module веб-сервера nginx. В этой статье рассмотрим, как тестировать этот вид ссылок в программе Postman , - как автоматически вычислять md5 хэш от переменных и постоянных параметров. Динамические параметры Postman В программе Postman можно использовать переменные, которые могу выступать и частью URL, и значениями параметров запроса. Так ссылка /s/api/v1/auth/?md5= 1pzX968MiqPu_ZvYYht5Xg &expires= 1704067200 из прошлой статьи с применением переменных должна стать такого вида: /s/api/v1/auth/?md5= {{md5}} &expires= {{expires}} Переменные удобно привязывать к настройкам окружения - кнопка с глазом - "Environment quick look" . Настройки окружения удобно делать для нескольких инсталляций сайтов (боевой, тестовый, локальный и пр.). В программе Postman просто переключать окружение и отправлять запрос на нужный домен. При этом все прочие параметры запроса остаются

Закрытое API: nginx secure link

Изображение
Допустим, есть API для сугубо внутреннего пользования. Например, взаимодействие мобильных приложений и сайта. API нигде не офишируется, нет публичной документации и вообще никаких упоминаний где-либо вне организации. Но само API открытое. Нет никакой 0Auth авторизации, или JWT, или ещё чего-то. В какой-то момент API начинает работать не только на внутренние цели, но и на пользу нежелательным сторонним пользователям. Начинают напрямую пользоваться API методами, тем самым создавая лишнюю нагрузку на серверах, утечку данных и прочие негативные последствия. Как открытое API превратить в закрытое? При этом не поломать старые валидные клиенты (хотя бы на переходный период). И в перспективе пресечь любые несанкционированные запросы через API. Тут приведу один вариант, полностью средствами веб-сервера nginx. Если кто-то знает ещё удачные варианты - пишите в комментариях. Модуль ngx_http_secure_link_module На странице официальной документации отлично описана польза, которую даёт применение это