User
Information
- Rating
- Does not participate
- Location
- Волжский (Волгоградская обл.), Волгоградская обл., Россия
- Works in
- Registered
- Activity
Specialization
ERP Developer, SAP-разработчик
Middle
From 1,000,000 ₽
ABAP
C++
C
PHP
Laravel
JavaScript
Web development
Для Европейской части России оно и сомнительно, тут интернет весьма развит. Для удаленных районов будет весьма полезно.
Судя по отзывам это зависит от региона. У меня родители уже N лет за талонами не ходят, вся запись через интернет.
Получение паспорта - вообще без проблем. Записался, пришёл забрал.
А вообще у них там была кнопка жаловаться. Типа если долго, пишите. В ковидные времена и у меня и у знакомых пару раз было "в ответ тишина", после жалобы тут же звонок с предложением записать на удобное время.
Так ведь применение готового - тоже решение. Вы не пишите каждый раз новый фреймворк для сайта. В большинстве случаев берется готовое решение и допиливается. К примеру есть Vue, Angular, React. Никто не делает своего потому что удобнее использовать уже существующее. При этом новое может быть быстрее (и в работе и в разработке (после изучения) ), но все кругом пишут в основном на перечисленной тройке а не пишут что-то своё на нативном js.
Вот создатель $mol сделал своё, которое вроде по всем тестам бьёт перечисленное (по крайней мере по его словам), но не используют, так как
Нужно изучать
Нужно поддерживать
И вот уже сколько лет автор пропагандирует это новое, но народ не кидается на это новое. И уже тем более не будет кидаться писать своё подобное с нуля.
Задача ИТ - решать проблему бизнеса. А для бизнеса проверенное и массовое решение зачастую выглядит перспективнее чем что-то новое, пусть даже в этом новом есть свои плюсы.
Люди пишут "как в статьях" потому что так проще. Не только для тех кто пишет, но и для тех кто придет потом. И даже работодателю проще, потому что замену искать проще.
Чтобы написать своё, нужно не просто это написать, но доказать что это реально лучше. А так как (смотри абзац 1), то доказать что твоё решение лучше зачастую сложнее чем написать.
Фактически мало сделать свой GitHub, нужно привлечь туда разработчиков. Кто больше привлечет, тот выиграет эту борьбу.
Достаточно знать историю Римской Империи чтобы было понимание как это будет управляться и что будет способно удержать его от распада.
Всё дело не в размерах Империи, а во времени, требуемом для перемещения по Империи. Римская Империя для своего времени вполне соответствовала по масштабам из Академии. А то и была больше, учитывая тот же Селден получил планету на краю Империи и туда он не шибко то долго добирался.
Было бы интересно прочитать описание и созданный на его основе сайт. А то боюсь там фаза "Результат его работы можно будет отредактировать." будет весьма не простая.
Прям представляю как похититель детей настраивает VPN чтобы разрешать похищенным детям брать с собой электронные гаджеты
На самом деле при данной схеме понятно когда нужно начинать выполнять - когда мы дошли до точки ожидания результата (до начала event loop). Т.е. вот у нас есть код:
Замыкание выполнилось, в нем в event loop добавились задачи группировки. Их будет три штуки (так как три вызова функции getUserForId). И вот тут будут созданы три задачи
После этого запустится event loop. Он объединит все эти задачи в один пакет, вызовет замыкание, которое в свою очередь добавит четыре задачи (три вызова функции getProfilesForUserId + Batching::all). Т.е. стандартный event loop и выполнением задач, отличие в том, что задачи группируются перед тем как отправится на выполнение.
Если нужно выполнить 1-2 запроса, то выполняем их в отдельном Batching::run(..), результат отправляем куда на нужно, а затем запускаем следующие задание.
Кэширование тут делается на стадии данных, которые возвращаются. т.е. если вы возвращаете строки, полученные из БД, то будут они кэшироваться. Вернете объекты ORM - закэшируются эти объекты.
На самом деле тут как раз нет привязки к ORM или базе данных. Можно использовать API вообще без использование БД. К примеру требуется выгрузить файлы на FTP. Делаем вызовы, затем в пакетной обработке группируем по FTP серверам и производим загрузку. Если у нас несколько файлов для одного сервера, то будет установлено только одно соединение и через него все файлы загрузятся.
Конечно join будут оптимальнее. Но его придется писать руками для каждого случая. Ленивую загрузку в ORM не просто так придумали.
Благодарю. Нашёл несколько реализаций. Как раз то что нужно
https://github.com/overblog/dataloader-php
https://github.2u2.cc/lordthorzonus/php-dataloader
Как я понял при беглом просмотре, там загрузка идет только по одному ключевому полю.
А какая разница на сколько хостов, если у вас света нет, к примеру, минуту. Все хосты пришлют ответы которые потеряются раз вас нет.
Т.е. как я понял информация жива только пока ходит запрос. Как только вас нет, то запрос потеряется и вся его информация тоже.
У вас (или на промежуточном роутере) выключился свет на N секунд и все пакеты с паролем от крипто кошелька потерялись. Б - но это уже не слово безопасность :)
Это в любой стране так. Всё зависит от того, поддерживаешь ты нарушителя или нет.
А правообладатели обращались в rutube с запросом на удаление? Или они вообще не в курсе что есть rutube и поэтому обращений не было?
И каждая страна будет предоставлять такую услугу всем, кроме граждан своей страны.
Есть ещё отдельная категория людей, которая проверяет что бэкап хранится не на том же сервере.
Вам какой-то упертый попался. Обычно они сразу нахер посылают и трубку бросают.
Так я именно так и делал
Чем больше я задержу мошенников на себе, тем меньше времени у него останется на тех, кто может ему поверить
Не знаю. Я туда 100 лет не логинился, поэтому их нравов не знаю. Пришла СМС, "оператор" усиленно пытался узнать код из СМС.