megorit

id пользователя получаемый через api приложений действительно уникальный для каждого приложения. Это сделано что бы не было возможности получить реальный профиль игрока.

> есть ли ещё какие-нибудь книги, наподобие данных для общего развития, не привязываясь особо к конкретному языку

«Алгоритмы. Вводный курс» Томас Х. Кормен
«Алгоритмы. Построение и Анализ» Томас Х. Кормен, Чарльз И. Лейзерсон, Рональд Л. Ривест, Клиффорд Штайн.
«Алгоритмы введение в разработку и анализ» Левитин А.В
«Algorithms in a Nutshell, 2nd Edition»
«Логика» Виноградов С. Н. и Кузьмин А. Ф _ 1954
«Основы системного анализа» Спицнадель В.Н. (2000 г.)
«Семь навыков высокоэффективных людей. Мощные инструменты развития личности» Стивен Р. Кови

В первую очередь интересует Linux, но хотелось бы вместе с этим узнать, как дела обстоят на других операционных системах.

Начнёт заполняться свой (swap), в других ОС (windows) примерно такая же система, про "совсем другие ОС" - я не в курсе.

И в Linux и в Windows и в других ОС, для которых есть компиляторы языка Си, есть функция, если посмотреть описание, например, такой функции, как malloc, то мы увидим оттуда, что:

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

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

Про SWAP можно немного почитать тут.

Некоторые программы, такие как Photoshop например, будучи заранее зная, что оперативной памяти не хватит наверняка, имеют свои механизмы "свопинга", т.е. создание некоего подобия "подкачки" на диске. У меня например, при открытии одного шаблона (макета) Photoshop может легко "откусить" 100Гб с диска, а если ещё и история изменений большая - может и больше.

Отдельно хочу обратить Ваше внимание, что в Linux'е есть некий механизм "самосохранения" в ядре, который при определенных условиях начинает "убивать" процессы, вышедшие из под контроля. В какой именно момент времени это происходит - точно я к сожалению сказать не могу, т.к. ещё только в процессе изучения подобных механизмов, но подозреваю, что "выход из под контроля" - это когда процесс и его потомки (форки) начинают потреблять чрезмерное кол-во процессорного времени и возможно памяти. Я наблюдал такую картину во время DDoS атаки на сервер, в этот момент Linux начал "крошить" всё подряд, в т.ч. и веб-сервер попал под раздачу. Среди прочего, помню, что где-то в документации читал, что процессу можно установить соотв. "флаг" или "приоритет" влияющий на этот механизм.

*ещё раз раз обращаю Ваше внимание, касательно абзаца выше - я детально не изучал данный механизм и в документации "по быстрому" информации не нашел, по этому, в последнем абзаце - информация может быть не совсем точной.

Работа должна быть выполнена четко по заранее оговоренному ТЗ. Если результат удовлетворяет ТЗ, но не удовлетворяет заказчика (так бывает в 8 случаях из 10), заказчик оплачивает выполненную работу и заказывает правки отдельно или идет лесом.
В вашем случае жить в бесконечных правках или послать заказчика подальше, денег вы не получите в любом случае. В будущем брать работу с гарантией оплаты (на фриланс сервисах) или делить стоимость на выполнение ТЗ и последующую поддержку и первую часть брать в качестве предоплаты. Но самое главное у вас на руках должно быть четко прописанное и согласованное с заказчиком ТЗ. Не обязательно там должна быть его подпись, достаточно электронного письма с фразой типа "с техническим заданием полностью согласен"

Мне в своё время объяснили - ООП нужен в сложных проектах, которые поддерживают и кодят много людей. ООП позволяет привести код к определенной системе и при очень больших объемах кода помогает избежать повторений.

Тем не менее я и сам пилил свои говноCMSки и даже конструктор сайтов без ООП. Код получался лаконичнее, быстрее и проще.

Тут каждому своё - если что-то простое писать то ООП в PHP вовсе не нужен, на мой взгляд.

Интересно будет послушать мнения

1) Стоимость правок необходимо оговаривать заранее, как и весь порядок разработки;
2) Если вы это не обсуждали до того, как взяли предоплату, то по обычаям стоит сделать правки бесплатно;
3) Заказчик не считает макет строгим. Для него это набросок, как и для вас. Поэтому правки неизбежны;
4) Вы должны понимать и помнить, что в РФ клиенты очень капризны, скупы и не педантичны, поэтому работать сними сложно и неприятно.

Это может означать все что угодно, кроме работодателя ни кто точно не знает, что он под этим имел в виду.

Многопоточность. Один поток ждет ввода с клавиатуры, другой проверяет и подсвечивает синтаксис, третий часики в углу рисует, четвертый на фоне сохраняет текущее во временный файл...