roswell

Видит. Телефон сообщает. И сам оператор слушает, есть ведь еще и обратный сигнал. Регулирует мощность передатчиков, исходя из общей картины. Приказывает абонентским устройствам сменить частоту или базовую станцию (если абонент видит несколько) исходя из собственных соображений и чувства оптимальности. Приказывает абонентскому устройству поднять или снизить мощность передатчика.

Примерно так: у БС есть 25 клиентов, из них 10 рядом, 10 далеко, а 5 ближе у другой БС, которая не перегружена.
Тогда логика будет такой:
- 10 ближайшим приказать перейти на одну (или несколько) общих частот. Снизить на этих частотах выходную мощность. Приказать абонентам понизить мощность своих передатчиков.
- 10 дальним - приказать перейти на другую (или несколько) частоты, и поднять на них свою мощность. А клиентам так же подрегулировать мощность их передетчиков вверх - до достижения уверенной слышимости на БС.
- 5 которые у другой БС - велеть переключится на другую БС и одну из ее частот.

"Любит человек слова. Он думает, что называя - он познает. Но это не так" (с)

Modal window - это то, что перехватывает на себя фокус ввода и не позволяет делать ничего другого в программе, пока не будет закрыто. Этот термин старше не только интернета, но и графического интерфейса.
Confirmation popup, который вы описали, вообще-то совершенно не обязательно будет модальным. Игрушка вокруг может продолжаться, только конкретное действие ожидает подтверждения.

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

Во-вторых, встроенные функции - это вообще какая-то ерунда. Используется раз в неделю. Куда важнее умеешь ли ты пользоваться библиотеками. Вот где эрудиция-то проявляется. Сидишь ли на коленке колупаешь CURLOPT или используешь гузлю. mail или phpmailer. И так далее.
Как в анекдоте - ты уже не сам анекдот рассказываешь, а только номер называешь.

В-третьих, опять же, код мы пишем не на голом пхп, а с использованием своих моделей, фреймворка, тех же библиотек. То есть в современном коде редко можно встретить голую функцию пхп.
То есть это просто другой уровень. зачем тебе mb_strlen и mb_substr чтобы обрезать текст по заданной длине, если у тебя уже есть готовая функция, которая это делает?

В-четвертых, непонятно, зачем насильно какие-то функции зубрить если все равно через неделю забудешь. Какая проблема перед решением какой-то задачи быстро погуглить функцию?

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

cd ~

Если честно, то на рынке ИТ все сейчас очень сложно. Причин несколько, а анализ легко растянется на полноценную статью, даже была мысль написать наХабр и Линкедин по этой теме. Постараюсь коротко пройтись по основным трендам.
1. Доступность удаленной работы, соответственно регионы и Индия с низкими зарплатами ворвались на рынок.
2. Миф о высокой зарплате. Когда то так было, сейчас курьер Яндекс-еды зарабатывает больше, чем средний программист. Про продажников даже не хочу говорить, знаю людей, легко имеющих и по миллиону в месяц.
3. Мифы о легком старте. На самом деле точка входа в профессию достаточно высока, так как мало освоить навыки кодера, нужно еще иметь логическое мышление, знать математику, анализ, разбираться в предмете (физика для игр, экономика для 1С, производство для автоматизации и многое другое). И, возвращаясь к пунктам 1 и 2, за хорошую зарплату придется после пары месяцев курсов конкурировать с индусами, которые имеют по 10 лет опыта, с регионами, где есть специалисты с 20-летним опытом, готовые работать за зарплату джуна в Москве.
4. Отдельно выделю сильно усложнившиеся программы, сложность разработки, несмотря на множество облегчающих жизнь инструментов, за последние годы выросла достаточно сильно.

Как человек, проведший не один десяток собеседований (и изучивший пару сотен резюме) скажу, что рынок действительно перегружен людьми, которые ничего не понимают в ИТ, но окончили курсы и гонются за легкими деньгами. Найти среди этой кучи резюме хорошего специалиста становится сложно. Отдельная проблема - болтуны, у которых опять же хорошо подвешен язык, но нет понимания реальной работы ИТ. Когда к этому приложена низкая квалификация руководства, происходит беда - сотрудников много, зарплаты высокие, а реально всю работу тащит один старый сотрудник, который 90% времени занят мыслями что его не ценят и пора валить.

Надеюсь, ответил достаточно понятно)

Нормальная ли ситуация, при которой разработчика пытаются бросать в разные направления?

не нормальная.
но довольно обыденная. особенно у аут–сорсеров/стафферов.

я бы спокойно ушел в swift:
1. приятная (по крайней мере для меня) платформа.
2. ограниченный список устройств.
3. нет особой гонки технологий/фреймворков/etc.
4. достаточно востребованная область.
да и начнете не с нуля: база у вас уже есть.

Ваша идея не верна.

Надо порисовать на бумажке и убедится, что из строки S вы можете получить только строки вида S(k1)S(k2)S(k3)...S(kn), Где S(x) - x-ый префикс строки S, т.е. первые x символов.
При этом k1 >= k2, ... k1>= kn.

При чем все строки такого вида можно получить.

Доказывается по индукции по количеству операций. Изначально строка именно такого вида (k1=длина строки). После каждой операции, эта строка сколько-то раз копируется и как-то обрезается по длине. Поэтому любая полученная строка будет такого вида. И каждую такую строку можно построить: применяйте операции с k равными k1, k1+k2, k1+k2+k3... Так вы за n операций соберете все префиксы по одному.

Теперь, раз вам во входном файле задана подстрока результата, вам надо проверить, что эта строка состоит из подстроки S, за которой идут префиксы строки S.

Так, пример из условия bcabc состоит из подстроки bc и одного префикса abc.

В задаче не очень большие ограничения, поэтому можно в тупую для каждой подстроки i..j результирующей строки определить, является ли она суффиксом первой строки. Также для каждой подстроки первой строки можно определить, является ли она префиксом второй строки.

Потом нужно построить граф: из позиции 0 сделайте ребра во все позиции, где заканчивается какая-то подстрока первой строки в начале второй. Из позиции i>0 сделайте ребра во все позиции j такие, что подстрока i...j префикс первой строки.

Потом, если в этом графе есть путь из вершины 0 в вершину с номером длины второй строки - YES. Иначе - NO.

Это решение за квадрат, если подстроки искать не совсем в тупую: для проверки на суффикс внешний цикл ведите по правому концу, а внутренний - по левому концу убывая. Так можно сдвигать второй указатель, пока строка остается суффиксом, проверяя каждый раз только один символ. Похожим образом можно проверять все подстроки на совпадение с префиксом.

Можно попробовать вычислить корень быстрым алгоритмом. Но там сложно. Гуглите Karatsuba square root. Есть открытые реализации. Есть еще какой-то адский метод через быстрое преобразование Фурье, попробуйте погуглить и его.

Более простой в реализации, но менее быстрый метод вычисления корня - бинарный поиск. Храните l, r, l^2, r^2 и lr. По этим числам можно вычислить m=(l+r)/2, m^2, m*l, m*r без длинных умножений, а только складывая длинные числа и деля на 2. Вам надо поддерживать, чтобы l^2 <= n <= r^2. Изначально можно сделать l=1, r=10^51 (или больше - половина длины входного числа + немного, чтобы точно квадрат был больше n), потом делить отрезок пополам и отбрасывать ненужную половину.

Еще есть вероятностный метод через символ Лежандра/Якоби. Это будет самым быстрым методом.

Это как смотреть на последнюю цифру. Квадраты могут давать там 0, 1, 4, 9, 6, 5. Но нет ни одного квадрата, который оканчивался бы на 2. Т.е. если число заканчивается на 2, то можно сразу говорить, что это не квадрат. Это мы взяли остаток от деления на 10 (последняя цифра) и посмотрели, какие из них хорошие. Вот символ Лежандра - это такая проверка для модуля по любому простому числу (а не 10).

Если брать некоторое простое число p, то n может быть квадратом, только если символ Лежандра (n/p) - равен 1 или 0 (По научному: n - должно быть квадратичным вычетом).

Если брать небольшие (<64-битные) простые числа, то можно за линию считать n%p и потом вычислять символ Лежандра (n%p/p) по алгоритму через символ Якоби за O(log(p)^2). Когда подсчитали символ Лежандра и если он -1, то n - точно не корень.

Тут проблема в том, что это необходимый, но недостаточный критерий - если для какого-то p вы получили -1 - то это точно не квадрат. Но возможно можно подобрать такое число, что все ваши тесты дадут 1, а оно не квадрат. Поэтому надо брать много простых чисел. Скажем, 20. Желательно еще числа брать достаточно большими. Но их не надо искать каждый раз, можно захардкодить. Грубая прикидка говорит, что вероятность ошибки такого алгоритма 2^(-количество простых чисел).

Т.е. берете много простых чисел. Считаете для каждого n%p выполняя деление большого числа на короткое (один проход по массиву цифр). Потом считаете символ Лежандра. Если получили где-то -1 - то точно не квадрат. Иначе - скорее всего квадрат.

Можно совместить вероятностный тест и вычисление корня. Сначала проверьте парочку простых чисел на символ Лежандра для отсечения точно не квадратов. Еще проверку последней цифры можно сделать, это очень дешево. Если не отсеклись, то считайте корень. Так будет всегда работать правильно но будет быстрее работать в некоторых случаях.

Выключить вебсервер