Александр

Я какое-то время качал учебные видосы с youtube. И кое что добавлю. Видео публикуется в широком диапазоне размеров и кодеков.

Самый слабый размер - от

3gp 176x144
и самый толстый что я видел

webm 3840x2160

Последнее - это классифицируется как 4К видео. Так вот. Я думаю что нагрузка на ЦП определяется
размером видео. Который в свою очередь определяется толщиной вашего канала интернета
и физическим размером монитора. Плагин плеера должен иметь какую-то разумную логику
активации высоких режимов. Очевидно что на обычном FullHD монике нет смысла качать
графику выше чем пикселов покажет ваш моник.

Что еще может влиять на температуру? Наверное тип кодека. Из таковых я вижу VP9 и AVC1.

Кодек выбирается по непонятному мне алгоритму. Тоесть существуют видосы с одинаковым разрешением
но с разными кодеками. Зачем youtube это делает - непонятно. Но возможно для совместимости.

Вот как-то так.

Программисты, будучи студентами на 1-2 курсе изучают алгоритмы и структуры данных (АСД) чтобы
писать более эффективные программы. При этом задача использования DBMS им еще не ставиться.
На этом этапе они учатся оптимизировать и понимать разницу между o(1), o(n^2), o(lon(n)) и т.п.
алгоритмической сложностью. Сложность определяет, как будет работать выбранный алгоритм
при очень резком (шквальном) росте исходных данных. И если ты это не учил, то ты сто процентов
напишешь фигню и твой алгоритм никогда не завершиться, какой-бы мощностьи процессор у тебя
ни стоял. И вот чтобы дать анализ такой ситуации, как раз и нужны знания АСД. А работа на пределе
мощностей сегодня везде. Игры. Рендеринг 3д. Майнинг. Обучение языковых моделей.

Работая с MySQL ты этого не видишь т.к. часть алгоритмов скрыта от тебя под фасадом SQL API.
Но тебе и недоступны вышеперечисленные задачи. Их стек - шире чем тот что ты используешь.
И если ты собираешся всю жизнь работать на PHP/MySQL то скорее всего АСД тебе действительно не
нужны.

Разработчик был скорее всего не заинтересован чтоб любой игрок изменял сохранения игры.
Поэтому вопрос можно либо адресовать разработчику это игры либо просто забить на него.

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

Для повышения внутри аутсорсинговой (не продуктовой) комании на самом деле тебе ни ООП ни PHP не надо.
Надо просто спросить у твоего line-manager или ресурсного-менеджера какой план
твоего роста. И какие вопросы будут звучать на assesment. В обычном ассесменте нет ничего
сложного. Собирается комиссия из 3х и более человек. И с тобой просто беседуют. Узнают
твой опыт. Прошлые проекты. Задают вопросы по уровню квалификации. В составе комисси
обычно есть твой тех-лид. Обычно к ассесменту тебя хорошо знают. И у тебя есть характеристика.

По поводу твоей продуктовой компании. Здесь сложно что либо сказать но ты не должен распыляться
на всякое там ООП и прочее. Это никому не надо. Нужно готовиться только к релевантным вещам
которые есть в компании. Например - компания использует Laravel? Пройди сертификацию.
Это будет более полезный бонус чем безсмысленная философия про эти инкапсуляции и прочее.

Вообще ООП - это страшный моветон и им принято мучать джунов при поступлении.

Поднята интересная проблема я считаю. Даже после успешного программного выключения надо проверить что какой-то зомби не был поднят своим хозяином в маске Гая Фокса волшебной командой Wake On Lan.

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

P.S. Централизованное выключение с рубильника - вобщем-то правильное решение только надо проверить что нигде не пищат UPS-ники и нет ноутбуков на разрядке.

Я вот предложу пойти от происхождения слова. Что такое фреймворк если мы не знаем определения слова?
Фрейм - это рамка. Work - работа. Тоесть работа в рамках. Рамочная работа.

Безотносительно пользы или вреда от фреймворков уже можно предположить что это некое ужесточение
порядка процесса разработки. Разработчик ЯП - свободен. Разработчик фреймворка - менее свободен.
Фреймворк предполагает некоторую дисциплину в разработке user-stories. К примеру вы работаете
с акторным фреймворком (Akka) и вы не можеет просто так запускать вычислительные Threads
потому что это идеологически неверно. Вы должны декомпозировать задачу на набор функций-акторов
которые делают простое действие и передают результат другим акторам. Если вы вдруг резко вильнули
в сторону и затащили во фреймворк какую-то непонятную логику которая не ложиться на идеологию -
то синьоры-лиды сурово сдвинут брови и попросят вас немедленно откатить из feature branch все
что не соответсвтует. Такую ситуацию можно рассмотреть под разными углами. С одной стороны
хорошо что вы не виляете туда-сюда. Код получается гомогенный и понятный. Акторы. Сервлеты.
Bean-компоненты, SpringBeans, ApacheCamel компоненты e.t.c. С другой стороны если автор имеет
амбиции к использованию только своего кода - тут надо обсудить приемлемость такого подхода
в команде. Это - полюбому конфликт. А конфликты в корпоративной среде устраняются очень быстро.
С автором будет проведен разговор. И далее у него будут варианты - работать
в парадигме фреймворка или .. искать другие проекты. Здесь параллельно со фреймворком идут
техники управления людьми на проекте.

Еще одно лирическое отступление.

Недавно я читал комьюнити программистов языка Forth. Эти ребята - большие философы написания
кода. У них - практически нет не то что фреймворков но и даже библиотек. Просто такова специфика
языка. Чего-то нет - напиши сам. Скорее всего сама целевая платформа (микро-устройства) определяет
лимиты и фреймворки и либы просто не приживаются там.

При высокой нагрузке близкой к 100% пользователь может совершить транзакцию на создание объекта в базе. Сама транзакция может подвиснуть. Пользователь не дожидаясь ответа обновляет страницу и снова создает объект. Получается уже две транзакции в очереди. По итогу когда очередь доходит до выполнения имеем в базе два одинаковых объекта (созданных вплоть до ms) что ломает логику программы.

Очень плохо что вы довели систему до нагрузки 100%. Обычно concurrency работает хорошо когда мы не доводим до такого состояния. Есть даже такой термин thread starvation (голодание потоков) когда потоки никак не могут получить квант времени.

Без кода и лог-файлов тут нечего обсуждать. Я просто могу дать несколько направлений на подумать.

1) CQRS (Command-Query-Separation) - это шаблон разработки при котором команды на изменение данных и запросы на их чтение идут независимо и существуют как-бы в разных временных эпохах. Это дает возможность масштабировать системы довольно сильно. И такие системы обычно лишены блокирок.

2) Idempotency- это два свойства бизнес операций. Идемпотентность например предполагает что если платежная система дважды продублировала ваш платеж (MQ/сетевые replays) за покупку чашки Кофе например то это не означает что с вас банк снимет дважды деньги. На самом деле каждая ваша карточная операция имеет уникальный ID и с точки зрения биллинга будет применение платежа только 1 раз с одним уникальным ID. Второй платеж-дубль будет проигнорирован. Это свойство часто используется в Apache Kafka как один из способов поднять скорость и надежность.

3) Когда ваша база или сервер приложений находтся в состоянии как-бы "агонии" то не стоит пытатся добивать ее повторами операций. А стоит на некоторое время прикрыть канал операций. Или разорвать цепь предохранителя. Как делают в электрике при повышенной нагрузке. Есть такой шаблон Cirquit Breaker. Аварийный размыкатель. Netflix его активно использует.

Вот подумайте.

Я не понимаю зачем такое ограничение в названии топика?
Микросервисы и Spring - это как езда на лошади только галопом.
Или рыбалка только для пресноводных рыб.

В науке и технике такие форматы как double / long double / extended применяются уже давно и их
возможности полностью закрывают все мыслимые вопросы.

Например мы можем посчитать соотношение самой большой длины (диаметр вселенной) на
самую мелкую длину (переменная Планка) и это будет вполне себе число которое ляжет в эти
форматы.

Преподаватель вас заставил считать факториал 250? Это наверное троллинг. Зачем.
Для приближенного подсчета факториала есть например формула Стирлинга. Ее достаточно
чтоб получить порядок числа и первые значимые разряды.

А bigint и арифметикой можно и никогда не закончить вычисления. Это - как в криптографии.
Длину ключа увеличили всего в 2 раза. А всех дата-центров планеты Земля уже не хватает
чтобы в цикле прокрутить просто все значения этого длинного целого.

Какая у тебя клавиатура? Я не советую ничего учить на ноутбуке. Ноут - всегда был походным вариантом десктопа со всеми вытекающими. Ход клавиши плохой. Нет характерного щелчка при нажатии. И вообще набирать неудобно из-за того что сухожилия пальцев напряжены постоянно. Вы боитесь нажать чуть сильнее чтоб не дай бох не сломать чего в своем любимом Apple M1.

Вобщем купите геймерскую клавиатуру. Или какой-нибудь эксклюзив со щелчком для печати документов. Такие есть. На нем и учится слепой печати удобно. И безопасно для здоровья.

Я знаю что щас в топик набегут сторонники ноутбуков но послушайте программиста-электронщика-и-связиста. Я печатал на технике которую вы даже не знаете. На телеграфных аппаратах РТА-80. И все они по дизайну были продуманы для работы человека пальцами с учетом охраны трудна. Они все были удобнее чем самые лучшие клавиатуры ноутов. Подумайте о том что мировой опыт печатающей техники никтогда не тяготел к плоской
поверхности и малому ходу клавиш.

Хорошая клавиатура для человека - это например клавиатура фортепиано. Вот там и ход клавиш добротный.
И вы не боитесь раздолбать ничего. Рука - расслаблена. Можно печатать быстро и без оглядки.

Существует атака когда человек посередине канала (man in the middle) подсовывает свой dns и вы,
заходя в свой банковский кабинет попадаете на сайт-обманку. Дальше могут быть разные сценарии
но в целом доверие к доменному имени базируется просто на предположении что вы точно-точно
знаете что зашли в СВОЙ банк а не в фейковый.

Возможно DNS over https решает эту проблему ведь человек посередине уже не может вклиниться в
https соединение. Хотя и здесь тоже можно рассуждать на тему браузера и того какие сертификаты
изначально там установлены. Кто вам устанавливал браузер и сами сертификаты. Короче вопрос
нулевого доверия на каком-то этапе остается. Криптография кажется его никак не решает.

Поскольку топик тегирован PHP то я-бы предложил взять PHP фреймворки и смотреть как они видят себе реализацию шаблона например репозиторий. Я-бы мог рассказать о Spring Data Repository но боюсь что для PHP будут отличия и автор просто запутается.

Банда Четырех (юбилейное издание) описывает шаблоны проектирования .... эээ кажется на SmallTalk и С++. По крайней мере во Введении книги они об этом писали. Поэтому читая код надо уметь читать глазами сущности этого мира и не пугаться.

Что такое шаблон Store - я не знаю. Опять-же это специфика PHP скорее всего.

Что такое шаблон Сервис. Ну я вообще не рискнул бы его никак определять. Это КМК слишком размытое понятие и его надо срочно сузить. Хотя-бы до уровня техно-стека. Может сервис в терминологии SOAP это одно. Облачный сервис - может быть вообще другое. Короче архитекторы этих технологий будут бить друг друга здесь как епископы разных церквей друг друга за ереси.

Сервис для ООП - вообще седьмая вода на киселе. Вообще ООП надо начать и закончить на его полиморфизмах и наследованиях и поставить точку. Дальше - нет ООП. Дальше идет хаос и новые виды абстракций от вендора языка. Аннотации и аспекты и рефлексия и прочий бред.

В классический реляционных БД - никак. БД проектировались исключительно как сервер который "отвечает на вопросы". И при этом сам ничего не уведомляет.

Если нужно ловить события в той точке где они возникают - то лучшее место не БД а именно сервер приложений. И для хранения событий использовать топики Kafka или RabbitMQ.

Если этого всего нет - то тогда дергай запросы 1 раз в час. Другого выхода нет.

Я не специалист по C# поэтому по качеству кода не смогу ничего сказать. Но могу сказать по другой части.

Проект создан в 2 коммита. Это обман. Так не бывает. Программисты не делают проект в 2 шага. Обычно
идет некий итерационный процесс когда в течение дня. Либо в течение итерации разработки какой-то
фичи делается бранч. И вмерживается в мастер. Или делается отдельный коммит в мастер с описаием что делалось.
И тогда проект приобретает ИСТОРИЮ изменений. По истории видно как авторы работали. Что изменяли.

У проекта нет документации. Надо описать что это для чего и так далее. Нет инструкции по сборке.
Каждый разработчик должен иметь возможность собрать любой проект с гитхаба прочитав инструкцию.
Сборка - это не программирование. Это отдельный скилл. Почитай что такое сборщики. И это не среда
разработки. Это отдельный продукт. Обычно в консоли работает. Чтоб на сервере собирать проекты
в режиме автономного процесса без участия человека.

У проекта нет модульных тестов. Это говорит о том что нет возможности бытро проверить не сломалась
ли логика после изменений. Тесты надо добавить.

Нет внешних метрик здоровья проекта. Непонятно в каком состоянии щас он находится. Компилируется ли вообще? Посмотри как другие проекты в гитхабе выглядят.

В исходники нужно вставить текст лицензии. Подойдет любая из опен-сорцных.

Ну если человек по жизни - шепелявый то какие питчи не накладывай то все равно будет шепелявый.
А вообще задачу надо смотреть более широко. Не только голос но и согласные буквы. Слова-паразиты.
Паузы. Кашель. Шмыгание носом. Просто грамотность речи. Все это маркеры которые просто
приближают метрику к нужному человеку. Опять-же эти маркеры нужно было собирать заранее для всей выборки людей.

Вообще во всех задачах распознавания нужно брать как можно более широкий вектор параметров.

В тексте вопроса написано много чепухи. Java может использовать внешнюю память. Кажется еще
в Java 8 для Apache Ignite (и других NoSQL систем) были попытки использовать неуправлямую
память через ByteBuffer. История где-то об этом сохранилась я думаю.

Начиная с JDK-14 (могу ошибаться) завезли Foreign Memory API который оперирует с памятью
более продвинуто.

По поводу

в Java не надо следить за памятью

- неправда. Следить за памятью надо всегда. Иногда это делает разработчик (для С/C++)
а иногда это делает GC или умные механизмы borrow-checker (Rust).
Если не следить то долго работающие процессы пожирают всю память ОС
до тех пор пока не будут убиты через ОС OOM killer. Возможно под слежением
имелись в виду накладные расходы на работу GC? Но эта проблема специфична
только для приложений которые активно делают new и переживают хотя-бы одну
эпоху. Кроме того в Java есть несколько разных GC которые просто обнуляют
все тезисы например 2000х годов и обсуждать их надо уже совсем как другие
алгоритмы которые имеют другие свойства. Грубо говоря знания по GC очень
сильно устарели после G1, Shennandoh e.t.c. Нужно учить заново всё.

прикладной код Java - заменить на “прикладной код движка Java”

Это вообще невозможно прокомментировать т.к. идет жонглирование терминами без
определений. Что такое движок в данном случае - непонятно?

В любом случае тебе надо звать в студию этого загадочного Романа и не плодить свои домыслы.