Андрей

Так же перепробовал многие приложения. Остановился на самом простом и очевидном:

1. Планшет лежит там, где нет доступа ребенку.
   
2. Когда нужно, я достаю планшет ребенку с условием, что запускаю и закрываю приложения сам.
   
3. Если ребенок открыл другое приложение - то забираю планшет на сегодня.
   

Обычно 1-2 раза хватает, чтобы ребенок понял условие 2.
После этого никаких проблем с ограничением доступа!

Т.е. сложно понимаю, что "засунуть" в один объект, что в другой, что должно быть статическим методом, что приватным и тд.

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

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

Теперь задумаемся о декомпозиции всего этого хаоса. Мы находим какую-то задачу, которую выполняет наш код (например какую функцию вызвать для обработки каждого конкретного запроса) и выносим это в отдельный объект. Отправка email-ов - отдельный объект. Весь SQL зашиваем в отдельный объект. Соединение с базой - объект. Пользователи - объекты. Все - объекты.

И главное, у каждого объекта есть своя область ответственности. UNIX way. Каждый объект делает что-то одно и делает это хорошо. Бывает так что ну... нужно сделать так что бы один объект делал две вещи. НЕ вопрос, мы можем его попросить сделать что-то сложное, а он будет как хороший менеджер тупо делегировать работу другим объектом. То есть он и сложную штуку сделает, и сам не будет знать как она делается.

А все безхозные функции, которые не пренадлежат никаким объектам (например функции порождающие объекты) можно вынести в статические методы. Главное что бы статичесих переменных у нас небыло (ибо это те же глобальные переменные). И поменьше публичного ибо черт его знает что эти разработчики будут использовать. Причем "те разработчики" это вы завтра.

Вообщем писав всё время на процедурке, сложно перейти на ооп.

Просто не думайте что это что-то "принципиально другое". Это та же самая процедурка, просто благодаря классам и объектам, вы можете порезать систему на маленькие модули. Данные будут лежать рядом с процедурами и у вас будет больше контроля за происходящим.

Вы можете начать погружаться в ООП с того, что разобраться "почему глобальные переменные это плохо", почему "состояние порождает сложность" и что такое эта "сложность" (многие почему-то думают что сложность выражается в написании кода а не в его чтении или поддержке), почему "изоляция" (и как следствие инкапсуляция) - это хорошо. Как это все соотносится с декомпозицией. Что такое "ответственность", что такое зависимости, связанности

Подскажите, какой проект начать писать (гостевая, блог), или может начать изучать фреймворк.

Фреймворки универсальны, а значит чистого ООП там быть не может. Во всяком случае нет ни одного фреймворка на котором стоит учиться ООП.

Есть хорошие упражнения на развитие понимания объектно-ориентированного проектирования. Например вот: https://habrahabr.ru/post/206802/

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

Или может подскажите книгу/сайт где пошагово в ооп написан какой-то проект, чтобы быстрее пришло понимание.

Так вы научитесь делать один конкретный проект а на втором вы уже проиграете. Так дела не делаются. Надо разобраться с причинами появления идеи ООП. Ну то есть что было до. Можно еще с функциональным программированием попробовать разобраться. В PHP оно слабо применимо, но основные идеи очень тесно переплетаются с ООП и познав немного функциональщины ваше ООП будет лучше. Да и если про ООП вы можете найти много булшита, про функциональщину врут мало.

Не понятно какое именно хранилище вам требуется. Если просто ftp/sftp, то выше уже упоминали Hetzner, также сюда можно добавить ihor с ценой 1 ГБ = 2 руб (Москва), ну и, например, еще Рустелеком (Германии), вот их цены:
Если же вы предпочитаете варианты S3/swift-хранилищ, тот можете глянуть на того же OVH, Селектел и др. Также хватает и доступных вариантов VPS с большим диском, если вам нужно именно это, могу пар-тройку перечислить.

Также с вашими объемами вполне можно использовать и CDN, что выше тоже упоминалось.

Однако Вы себе напридумывали. Давайте разберемся по-порядку.
Внимание! Будет многабукав и много юридической информации.

Итак, как к нам поступают деньги от клиентов Upwok?

1) Клиент передает деньги Upwok'у. Ну тут как бы все чисто, никаких проблем. Деньги-то не у нас. Де-факто (и де-юро тоже) деньги перечислены на счет в банке или иной кредитной организации, который принадлежит Upwork.

2) Upwork зачисляет деньги на наш "счет". [s]И тут Вы впадаете в панику.[/s] Давайте начнем с того, что деньги, как таковые, никуда не двигались. Они как лежали на счету Upwork'a в банке, так и продолжают там лежать. Upwork лишь рисует небольшую циферку у Вас в профиле и все. Ни юридически, ни фактически эти деньги Вам не принадлежат*. Upwork не является ни банковском, ни кредитной организацией, ни фондом ни иным лицом, уполномоченным производить операции с чужими денежными средствами. Все денежные средства, поступающие на его счета от заказчиков становятся денежными средствами Upwork. А то, что Upwork выплачивает эти суммы Вам - это он распоряжается принадлежащими ему деньгами. Т.е. выступает не просто посредником, который передает деньги из одних рук в другие, а промежуточным собственником. Как если бы вы купили автомобиль у одного товарища, оформили его на себя, а потом продали/переоформили его другому товарищу. То, что в Вашем профиле отражаются какие-то суммы с обозначением валюты, это не отражение состояния какого-то пресловутого счета - у Вас его на Upwork'e нет и быть не может - чисто юридически это просто обещание Upwork'а выплатить Вам сумму, эквивалентную указанной. И все. К этому моменту Вы еще не собственник этих денег, вы не можете их потратить.

3) Upwork "выводит Ваши деньги" (а де-юре просто перечисляет на Ваш счет из своих), и вот тут возможны варианты:

3.1) Upwork перечисляет деньги на Ваш банковский счет - проблем нет, все чисто. С точки зрения налогообложения возможны трудности, если это счет в иностранном банке, но это не проблема, а именно трудности, и их тут разбирали.

3.2) Upwork перечисляет деньги на Ваш счет в небанковской кредитной организации. Опять варианты:

3.2.1) Это PayPal или иная небанковская кредитная организация, которая официально зарегистрирована на территории РФ и включена в соответствующие реестры - проблем нет, все чисто. Эти организации имеют право осуществлять операции с валютой (при наличии лицензии, при ее отсутствии они автоматически переведут эти средства в национальную валюту, т.о. доллары Вы не получите).

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

И да, статья 15.25 КоАП РФ фактически запрещает расчеты в валюте на территории России в обход банков. Вот и все.

_____________
* В соответствии с действующим отечественным законодательством (что, кстати, полностью согласуется с общепризнанными принципами и нормами международного права) право собственности включает в себя 3 элемента: владение (фактическое обладание, включая принадлежность депозита), пользование (возможность извлекать из вещи пользу) и распоряжение (возможность определять дальнейшую юридическую судьбу вещи; применительно к деньгам - тратить их). Нет хоть одного из элементов - нет права собственности. Нет права собственности - нет проблем.

"я просто не понимаю, что нужно делать" - это значит, что тебе рано думать о собственном бизнесе. На этом этапе это будет бизнес ради бизнеса, такой бизнес приводит к печальным последствиям(в лучшем случае ты расстанешься только со своей десяткой), бизнес должен приносить деньги, в этом его единственный смысл. Мой тебе совет: "Деньги не трогай, пусть лежат там, где они лежат. Устройся на работу в компанию, которая аналогична той, которую ты собрался открывать. Разберись с бизнес-моделью, шпионь по полной, ни в чём себе не отказывай, рано или поздно ты обязательно поймёшь, что нужно делать." Удачи тебе.

Кажется, тут какой-то перекос в веб-разработку. Вот Гугл предлагает путь на https://www.google.com/about/careers/students/guid... . Наверно, разработчик это не о технологиях, а скорее о навыках решать задачи.

Проиндексируйте значения для двоичного поиска. Создайте отдельный массив, в котором храните отсортированные значения city и номер объекта в исходном массиве.

Не ищите даже, не пытайтесь заниматься преждевременной оптимизацией не смотря на соблазн). Высоконагруженный проект можно построить без спец.знаний, просто на практике, оптимизируя и дорабатывая приложение. Сколько бы вы не читали статей и литературы, все равно неизбежно будете переписывать код, менять структуру БД и писать миграции. Кроме того, важно иметь хороших админов

В качестве веб-сервера используйте nginx в чистом виде (а не как прокси над apache итп). Используйте redis - с его помощью можно снять нагрузку с mysql во многих случаях. Изучайти инструменты, которыми пользуетесь. Особенности БД, индексы, типы данных. Расширяйте набор инструментов. Есть специфичные СУБД типа cassandra. Что касается хранения файлов - старайтесь избегать хранения более 2000-3000 тысяч файлов в одном каталоге. Разбивайте на подкаталоги. Это пожалуй все, что я могу сформулировать. Остальное сами поймете на практике

я больше 20 лет в программировании (от джуниора до senior, team lead, etc) и всё равно иногда возникает впечатление, что где-то я до сих пор джуниор.
Языки изучать надо. Фреймворки - пустая трата времени

Главное отличие senior/lead от мидла и джуниора в том, что сеньор способен делать таск, не задавая технических вопросов.

Он сам способен разобраться в системе и сделать то, что надо быстро и качественно.

От сеньора никогда не услышишь, что это "сложно" или "невозможно" - он просто садится и делает.

Все это называется "профессионализм" - и именно он является главной чертой сеньора. А те фреймовки и языки, которым он пользуется - лишь инструменты.

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