В настоящее время занимаюсь web-разработкой
В данной статье пойдёт речь об особенностях UEFI на примере переноса Debian Stretch с MBR на UEFI. Опишу так же разницу между MBR и UEFI, так как я её воспринимаю.
Кроме общей части, ключевая часть статьи про формирование GRUB EFI файла grubx64.efi во время grub-install и про то, что этот файл не так прост, как кажется на первый взгляд.
В октябрьском дайджесте PHP и Laravel: выход PHP 8.4.0 RC3 и подготовка к финальному релизу 21 ноября, важные обновления безопасности в PHP 8.2.25 и 8.3.13, множество улучшений в Laravel 11, включая новые функции для работы с Enum, расширенные возможности middleware, оптимизации производительности Schema и улучшенное логирование очередей. Также рассмотрены новые атрибуты RouteParameter и CollectedBy, добавление директивы @bool в Blade и другие изменения. Будьте в курсе новостей!
Приветствую, всех!
Я думаю, многие не только на Хабре, читали ядреные новости о Linux и Open Source. Если кратенько, то из мейнтейнеров ядра Linux исключены русские программисты работающие в подсанкционных компаниях.
Это статья написана от души и для души. Она не является: инструкцией, примером для подражания, призывом к действию или чем-то подобным.
Я абсолютный новичок в программировании, поэтому могу ошибаться в некоторых (или даже во многих) вещах. Я бы, наверное, даже не писал эту статью. Однако, проведя некоторое время в сети, мне так и не удалось найти похожий на мой проект. Именно поэтому я решил поделиться своей идеей с вами.
Так исторически сложилось, что задача организации простого и понятного резервного копирования в мире PostgreSQL до сих пор не решена. Есть набор комьюнити утилит, у каждой из которых есть некие плюсы, но всегда в нагрузку будет прорва минусов (тут нет инкрементных копий, там нет внятного расписания, это может только весь сервер вместо конкретной базы увозить и так далее). Да, есть тяжёловесный энтерпрайзный софт за много денег, зачастую требующий странного и работающий по какой-то своей логике, но это тоже не панацея. А вот чтобы просто и понятно, без головных болей организовать прозрачный процесс банального бекапа с инкрементами, работающим расписанием и восстановления только того что надо - вот такого нет.
Но буквально на днях вышел PostgreSQL 17 и может там что-то изменилось? И да, и нет. Та самая мана небесная в виде pg_awesome_backup_tool так и не появилась, однако в релиз попал механизм walsummarizer, который обещает нативно отслеживать изменения в файлах баз данных, что позволит делать инкрементальные бекапы нативно и без лишних приседаний.
А чтобы не рассматривать новичка в вакууме, будем сравнивать его с ptrack - нашей (Postgres Professional) разработкой, которую наши любимые конкуренты уже расхватали в свои продукты и продают их как уникальнейшие решения.
Это дайджест новостей от CutCode. Сергей Пантелеев и Данил Щуцкий с ежемесячным обзором новостей в мире PHP и Laravel.
Привет, Хабр!
Laravel — это целая экосистема, которая позволяет разрабатывать веб-приложения с невероятной скоростью и гибкостью. Но вот вопрос: как быть уверенным, что все эти красивые строки кода не развалятся в самый неподходящий момент? Ответ очевиден — тесты!
Иногда мы пишем SQL-запросы, мало задумываясь над тем фактом, что сначала они должны быть по сети как-то доставлены до сервера, а затем их результат - обратно в клиентское приложение. Если при этом на пути до сервера присутствует еще и пулер соединений типа pgbouncer, дополнительно "перекладывающий" байты между входящими и исходящими коннектами, ситуация становится еще тяжелее...
Поэтому сегодня рассмотрим некоторые типичные ситуации, в которых разработчики иногда принимают не самые оптимальные решения, гоняя по сети мегабайты трафика при общении с сервером PostgreSQL - а заодно посмотрим, как можно увидеть такую ситуацию в плане с помощью explain.tensor.ru и подумаем над вариантами, как сделать подобное взаимодействие более эффективным.
Сегодняшняя тема посвящена нелегким взаимоотношениям клиентского приложения и сервера PostgreSQL: как на ровном месте, неудачной архитектурой приложения, можно обеспечить себе хронические проблемы производительности.
Рассмотрим классические ситуации, когда разработчики начинают жаловаться на производительность БД - а виновата-то и не она!
Статья про то, как я изменил стандартное поведение нормализации ввода и решил проблемы валидации, возникшие из-за этого. В статье упоминаются слова ООП, наследование, фабрики, сервис-провайдеры и другие.
Данный пост нацелен на неопытных PHP-специалистов. От этой информации лучше программировать вы не станете. Ожидаемая польза:
Мне когнитивно и морально легче, когда уменьшается «магия» того, с чем работаешь. Может тебе тоже
Возможно чуть-чуть реже статьи на хабре будут тебя отпугивать
Объясню на 4 примерах — каждый лишь немного сложнее предыдущего.
Пример 1: запуск программы, написанном на компилируемом языке (Go): в полной статье
Пример 2: Запуск скрипта PHP без OPCache и JIT
В интерпретируемых языках подразумевается, что при запуске программы будет осуществляться выполнение машинного кода не сразу. В случае PHP — запускается именно исходный код.
Это означает, что при каждом запуске программы система должна проанализировать исходный код и преобразовать его в понятный код для процессора (т.е. в машинный код).
Вот схематично представил всю последовательность работы PHP скрипта без включенных OPCache и JIT (каждый из них по отдельности рассмотрим в следующих двух примерах).
У нас привычный «исходный код» PHP (файл hello-world.php):
<?php echo "Hello world";
Опять идем по порядку, рассмотрим какие процессы происходят запустив команду:
php hello-world.php
Процесс №1 — Компиляция в байт-код
Сначала исходный код обрабатывается Zend Compiler — это PHP компилятор. Первый из двух основных компонентов Zend Virtual Machine.
В отличие от рассмотренного выше компилятора Go:
задача PHP компилятора — преобразовать исходный код не в машинный код, а в код-посредник - байт-код;
процесс компиляции происходит при каждом запуске программы (вместо лишь единоразового - до запуска программы, как в примере с Go)
В случае PHP этот байт-код назвали PHP OPCode.
Байт-код — является более низко-уровневым, чем исходный код. Он содержит набор команд для интерпретатора (об интерпретаторе в следующем пункте). Байт-код не может выполняться процессором напрямую.
Чтобы посмотреть результат работы компилятора — сам байт-код — выполним команду:
php -d opcache.opt_debug_level=0x20000 -d opcache.enable_cli=1 hello-world.php
Получим:
$_main: ; (lines=3, args=0, vars=0, tmps=1) ; (after optimizer) ; /hello-world.php:1-2 0000 EXT_STMT 0001 ECHO string("Hello World") 0002 RETURN int(1)
Вначале видим $_main: — обозначает, что следующие строки относятся к функции main. Появление такой функции в байт-коде для глобальной области видимости PHP — занятная историческая особенность, дошедшая из других языков;
Следующие 3 строки начинаются на ; — так обозначаются комментарии. Одна из целей — для дебаг-информации;
Последние 3 строки — непосредственно код нашего приложения, который будет выполняться виртуальной машиной в следующем шаге.
Процесс №2 — Выполнение байт-кода
Следующий возникающий в голове вопрос, когда разобрался с тем, как работать с данными в данной архитектуре (а может у кого то этот вопрос стоит первым) - как микросервисы будут взаимодействовать между собой?
В данной статье разберемся с синхронным и асинхронным взаимодействием, сложностями и разными подходами.
Приветствую тебя читатель, я решил написать про ACID и Транзакции PostgreSQL своим языком, с понятными примерами, эта статья ориентирована на людей готовящихся к собеседованию, кто захотел узнать нюансы транзакций в PostgreSQL или про ACID, а также для людей которые знают теорию, но сами ещё ни разу не писали транзакции. Я не ставил перед собой цели рассмотреть и объяснить работу транзакций на очень глубоком уровне. Была цель привести понятные примеры, дать макет работы с транзакциями, а также пощупать основные возможные проблемы при работе с транзакциями в PostgreSQL.
Это третья часть статьи, в которой мы научимся работать с базами, ролями, консолью, а также политиками подключений.
На связи Егор из блока поддержки платформы F5, сегодня предлагаем вспомнить основы systemd. Поскольку утилит и возможностей в нем много, а новые функции добавляются регулярно, следить за всем этим может быть непросто, так что начнем с основ.
Systemd — это init процесс, который запускается при загрузке ядра операционной системы linux и его задачей является форкать другие процессы. Информацию о том, какие процессы необходимо исполнить он берет из, так называемых “юнитов” (systemd unit - https://www.freedesktop.org/software/systemd/man/latest/systemd.unit.html). Юниты бывают различных типов, каждый из которых выполняет определенную задачу.
TL;DR В статье рассказывается о доступе к внутрикорпоративным ресурсам через соединение Forti из подсистемы Windows для Linux (WSL).
При разработке сайта важно уделить внимание тому, насколько он будет удобен и функционален, отображаясь не только на экране компьютера, но и на экранах других устройств. В этой статье мы расскажем, что значит «правильная адаптация» сайта, как именно работает мобильная оптимизация и чем чревато ее отсутствие.
Итак, что мы вообще знаем о том, что такое оптимизация? Это процесс, при котором frontend-разработчик и web-дизайнер адаптируют верстку сайта под размеры и функционал других устройств, помимо компьютера. Делается это для того, чтобы интерфейс сайта, а также текст и визуальные элементы отображались и функционировали корректно и на смартфоне, и на планшете, и на других устройствах, отличных от компьютера.
Добрый день, коллеги! Как известно, компания "Postgres Professional" более не рекомендует использовать секционирование с использованием pg_pathman, а рекомендует использовать вместо него декларативное секционирование. Однако помимо синтаксического сахара и утилитарного кода по поддержке интервального (в стиле Oracle) секционирования, я обнаружил для себя ещё одну проблему в такой миграции (переходе). Надеюсь, коллеги из PGPro доработают декларативное секционирование к моменту окончательного выпиливания pg_pathman.