Веб-версияОткрыть в Telegram
PPhp Noobs — сообщество новичков и не только.

Php Noobs — сообщество новичков и не только.

@php_noobs_ru · группа · Технологии · в индексе с 2026-07-04
25участников
2 531сообщений в индексе
F
Так что хорошие зарплаты получают программисты
V
Кто знает про wordpress, подскажите, что там насчёт вёрстки/фронтенд, можно сделать любую по своим желаниям? И функционал подключить тоже +- можно нормально например зная нормально Php? Я сам долёк от wp, просто сестра там кое что толи заказывала чтоб сделали толи еще будет еще раз заказывать, т.к. не один не второй 'разработчик' не сделал что нужно.
V
Ссылка
нажмите — покажем
Связи с тем что есть группа по Nuxt, в которой часто некоторые пользователи отговаривают от полноценного использования Nuxt.js на frontend + backend. Если кто то тут пишет на Nuxt.js или интересуется Nuxt.js, приглашаю в только что созданную группу по Nuxt.js. Там в основном планируется чат о Fullstack разработки с использованием Nuxt.js, который по верх Vue.js, а Vue.js поверх JavaScript. :) https://t.me/+gm0t9svMUAY5OTA8
  1. V
    Всё же я Nuxt.js фреймворк оставлю в основном для фронтенд части и может быть иногда для мини fullstack. Ибо я начал пробовать изучать для JavaScript-backend части Nest.js.
Вся ветка · 1 ответ →
Н
Добрый день. Подскажите пожалуста, как лучше реализовать такую фичу? Я со своего пк создал задачу, со статусом "новая", назначил её на человека, человек на своём устройстве взял её в работу, поменял статус на "в работе", выполнил и поменял статус на "выполнено". Вот как мне сделать так чтоб я мог отслеживать статус задачи без перезагрузки страницы, чтоб когда он менял статус, то я тоже у себя сразу видел изменения?
  1. M
    Добрый день Как вариант, можно попробовать вебсокет
Вся ветка · 1 ответ →
V
Такая мысль пришла, почитать не много о том что изменилось в Php за последние примерно 4 года.
V
Я только с vanilla Php в основном был знаком, Php фреймворки не использовал.
V
Что нового у Php? Всё еще позволяет решать задачи самостоятельно на Php, или Node требуется всё больше и больше?
И
🚀 NitroCache: Rust + PHP FFI против тормозов на Windows Сделал NitroCache — нативный кэш-движок на Rust, который общается с PHP через Shared Memory и FFI. В чем фишка: ✅ Zero Network Overhead: Никаких сокетов и TCP/IP стека. Прямое чтение из памяти. ✅ Скорость: Задержки (latency) всего ~16-20 мкс. ✅ Zero-Config: Один .exe и одна .dll. Никаких контейнеров и сложной настройки. ✅ Persistence: Данные живут в памяти, даже если PHP-скрипт завершился. На бенчмарках выдает стабильные 60,000+ ops/s на чтение/запись. Проект в альфе, код открыт под MIT. Буду рад фидбеку по реализации FFI и вашим звездам для мотивации! ⭐️ GitHub: https://github.com/mamontil/nitro-cache
  1. А
    Привет. Честно посмотрел по диагонали, но все же назрел ряд вопросов и уточнений: 1) А какую задачу решает данный кеш-движок? 1.1) Это замена Memcached? — как я заметил ты по сути хранишь данные на диске используя единичный файл, что при увеличении объема данных должно сильно сказаться на скорости чтения\записи — ты фактически зависишь от файловой системы и ее пропускной способности 1.2) Это замена Redis? — В отличии от Редис - ты сразу работаешь с диском, Редис же хранит все в памяти и делает "сброс" данных на диск для формирования персистетности хранилища 2) Использование pipe через kernel32 - ты фактически завязываешься на Windows 2.1) Какой смысл библиотеки расширения для PHP под Windows? === 3) Если реализация носит характер - "код ради кода" или "посмотреть смогу ли я" - да, супер! круто! А вот практического применения крайне мало.
    1. А
      В части моего заключения об использовании "файловой системы" - здесь я скорее всего ошибся. PIPE это механизм SharedMemory - то есть по сути это память
    2. И
      Привет! Спасибо за детальный фидбек, круто! Конечно, это не убийца Redis для кластерных систем. В отличие от Redis, здесь нет накладных расходов на сетевой стек По поводу диска: работа идет через проецируемые в память файлы или через системный кэш ОС. Для небольших и средних объемов данных это работает на уровне L3-кэша процессора/оперативки, так как ОС держит горячие куски файла в памяти. Многие пхп разрабы сидят на винде, и стандартные средства работы с файлами там часто медленнее, чем на линукс Это был вызов: реализовать максимально производительную систему, используя нативные механизмы ядра, а не медленные файловые блокировки Есть кейсы, например, в локальных парсерах, где нужно быстро перекидывать данные между процессами без поднятия тяжелой инфраструктуры типа Редис В планах есть добавить поддержу для Линукс, если поймаю мотивации и найдется свободное время.
      1. А
        Так разработка на то и разработка - что ты делаешь, отлаживаешь, а потом запускаешь на ПРОДе. А ПРОД в 99% это Линукс. Да и вообще проще поднять WSL или Виртуалку с Линуксом что бы быть ближе к ПРОДу.
        1. И
          Нет реального продукта, куда бы я это поместил. Можно сказать это воплощенная фантазия. Может кому то пригодится в реальном проекте.
          1. А
            В части - "воплощения фантазии" - супер! отлично! Код хорошо структурирован (для РАСТа). Вариант использования через FFI - хорошая практика для возможности создания свои фич (хотя уже 95% всего что только может потребоваться - сделали) Но велосипедостроение - вещь почетная! (без сарказма)
      2. А
        ИМХО не лучший вариант использования инструмента. Рано или поздно ты пройдешь (последовательно) следующие стадии: - моя либа работает в одном процессе и в другом - я хочу не зависеть от ОС в части хранения данных - я сделаю отдельный сервис который сам будет принимать коннекты, хранить данные и отдавать их = ты сделал Memcache
        1. А
          И ты поймешь, что потеря на коннект это мелочь по сравнению с удобством и расширяемостью. Ну и главное... "Господа вы чего такоего делаете что вам поднятие сокета медленно??"
          1. И
            ДА всё наверное так, это правильное порицание
Вся ветка · 10 ответов →

Открытая публичная лента из поискового индекса ChatCrawler — «Google по публичному Telegram»; обновляется по мере обхода площадки. Время — UTC.

Только публичный контент, официальный API Telegram. О проекте · Вопросы · Чего мы не делаем · Убрать страницу из выдачи · Каталог · Поиск · Как мы считаем