ThunderCat

ORDER BY date DESC 
LIMIT 2

Получите последнюю и предпоследнюю записи.

Я просто вставляю order by date (поле даты) и забираю последнюю строчку.

Глупо.

Используй ORDER BY date DESC - и тогда можно, во-первых, брать первую строку, а не мотать вниз до последней, во-вторых, нужная "предыдущая" строка при обратной сортировке будет "следующая" - ну то есть вторая.

PS. Дата - ненадёжный критерий сортировки. За один день комп могут сдать на склад и выдать другому товарищу - и будешь ты гадать, какая из двух записей актуальная, а какая для неё предыдущая. Я уж не говорю о вводах и корректировках "задним числом".

У вас файл создан под Уиндоуз, в которой в качестве разделителя строк используется последовательность \r\n
Разбивая по \n, вы в конце каждой строки оставляете висеть символ \r, и в итоге при сравнении совпадает только последний элемент файла, после которого нет перевода строки

Для чтения файлов в РНР есть специальная функция. Которая понимает любые переводы строк, и умеет их автоматически удалять.

$array = file(JPATH_SITE.'/list.txt', FILE_IGNORE_NEW_LINES | FILE_SKIP_EMPTY_LINES);

И всё сразу начнёт находиться.

Чтобы ограничить количество выводимых страниц требуется знание арифметики в пределах начальной школы.
Чтобы вместо 1 и $num_pages использовать заранее рассчитанные значения, укладывающиеся в определённый интервал. Например 10 страниц.
То есть надо всего лишь определить начальную и конечную цифры, которые подставлять в for вместо 1 и $num_pages.
Например, если мы хотим выводить только 10 страниц, а текущую выводить посередине то для получения первой цифры надо отнять от текущей 4. Затем к ней надо прибавить 9 - так мы получим второе число.
При этом, разумеется, надо проверить, чтобы первое не было меньше 1, а последнее - больше $num_pages.
А дальше просто подставить их в for. Вот и всё.

Почему «пропали» коммиты?

Главная ошибка — использование --amend во время rebase.
Команда git commit --amend не создает новый коммит, а перезаписывает предыдущий.

Когда вы время интерактивного rebase на каждом шаге делаете --amend, вы по сути всё время заменяете один и тот же коммит. Остальные коммиты, которые Git должен был «применить» в процессе ребейза, просто исчезают, потому что их заменили.

Как делать правильно?

Во время rebase -i вместо amend нужно:

git add <файлы> #  главное проиндексировать правки файлов
git rebase --continue # тут гит уже сам сделает git commit --no-edit

Вручную делать git commit перед continue имеет смысл только если вы хотите поменять ещё и сообщение коммита.

Как восстановить утерянные коммиты

Git не удаляет коммиты сразу. Они остаются в репозитории и доступны в reflog — журнале ссылок.

Их можно найти так: git reflog

Затем восстановить ветку: git reset --hard <хеш_из_reflog>

Вывод

Это не баг Git, а ожидаемое поведение. Просто rebase + amend — взрывоопасная смесь, особенно если не до конца понимать, что происходит.

Неделя начинается с понедельника и идентифицируется своим порядковым номером в году. Первой календарной неделей года считают первую неделю, содержащую первый четверг текущего года. Последней календарной неделей календарного года считают неделю, которая предшествует первой календарной неделе следующего года. ISO 8601.
Соответственно, 2024-12-29 - воскресенье, последний день последней, 52-й недели года.
2024-12-30 - понедельник, входящий в неделю, где четвергом является 2025-01-02, то есть в первую неделю 2025 года.

location ~ ^/phpmyadmin/(.+\.php)$ {
    root /usr/share/phpmyadmin;

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

URI = /phpmyadmin/index.php
root = /usr/share/phpmyadmin

В итоге nginx будет искать файл /usr/share/phpmyadmin/phpmyadmin/index.php

Если в root убрать лишний /phpmyadmin.

location ~ ^/phpmyadmin/(.+\.php)$ {
    root /usr/share;

nginx будет искать файл /usr/share/phpmyadmin/index.php

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

Коротко - потому что IEEE 754

Выполняет он математические операции правильно, но некоторые числа компьютер просто не способен представить со 100% точностью, тк для них нужно было бы бесконечное количество памяти.

Точно также, как мы не можем записать все цифры числа 1/3 в десятичной системе, точно также и компьютер иногда не может записать все цифры в двоичной.

Если ты работаешь с деньгами, то тогда используй то, что делают все банки - представляй суммы денег не как дробные числа, а как целые. Например место 1.5 рублей записывай как 150 копеек. Запятую добавишь при выводе человеку.
btw тут в комментах пишут, что для денег тоже есть паттерн по-лучше конкретно для php.

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

Если ты делаешь какие-то математические вычисления - возможно тебе нужны рациональные числа.
Не знаю, что обычно для этого в пхп используют, но нагуглил https://github.com/webgriffe/rational
https://github.com/markrogoyski/math-php

Но в случае с целыми числами ты всё равно можешь упереться в ограничение на максимальное число, а в случае с рациональными числами ты получишь очень сильную просадку в производительности.

Если тебе критически важна скорость, а точность - не так важна, то оставайся на IEEE754 и просто округляй то N значимых цифр (обычно больше 5 цифр мало кому нужно)

Потому что типом данных double нет возможности представить число 0.58. Поэтому компьютер берёт наиболее близкое к 0.58 число, которое double может выразить.

Если вам нужны точные вычисления, то следует воспользоваться специальными функциями:

$format = bcdiv("580000000", "1000000000", 2); // "0.58"

var_dump(bcmul($format, "100")); // string(2) "58"

Существует даже специальный сайт, рассказывающий о данной особенности математики чисел с плавающей запятой: https://0.30000000000000004.com/

Проблем с временными зонами вообще не будет, если их представление выдавить максимально ближе к модели представления данных на интерфейсе пользователя.
Нужно конвертировать в строку только непосредственно перед отрисовкой дату и время из UTC, и обратно загонять время в UTC, если забираете пользовательский ввод.
Весь бек должен работать в одной временной зоне, а от пользователя знать, что он в такой-то временной зоне, только в контексте сессионной переменной, если это необходимо.

Видео в любом случае должно быть кем то сконвертировано, перед отправкой клиенту, варианты:
- Либо множество заранее подготовленных видео роликов с нужным качеством (ютуб так делает), потребуется сильно больше места на диске, но нагрузка на процессор будет сильно меньше + можно выбрать ночное время для обработки.
- Либо сервер, который будет конвертировать видео в реальном времени, но нагрузка на процессор будет сильно больше.