vildulv

Карту давненько не обновлял но может, что полезное найдешь для себя Карта развития Back-end разработчика

Для практики рекомендую взять что то из этого списка build-your-own-x, можно посмотреть как сделать простой веб сервер, поисковый движок, БД

Плюс вот еще статья Не убивайте свою мотивацию: осваивайте Ruby on Rai... хоть для руби, но есть список интересных проектов

Значит так, берем толстую тетрадь, ручку и пишем фразу "Статические методы не имеют отношения к ООП" до тех пор, пока не запомним это на всю жизнь.
Суть объектно ориентированного программирование, как понятно из названия, заключается в том, что должен существовать объект. Статика существует не в контексте объекта, а в контексте класса! Из этого вытекает то, что на протяжении всего жизненного цикла вашего кода будет существовать лишь одно глобальное состояние статических членов класса.

Использовать статику нужно в случае, если то, что вы ей описываете принадлежит всей группе объектов, а не одному. Например, у класса Human может быть статический метод numberOfLegs(), который возвращает количество ног у людей. Количество ног - это общее свойство для всех людей (Речь идет о здоровых людях). В данном случае можно было использовать константу класса, но это не так важно, ведь, по сути, константа - это тоже статический контекст. А вот имя - это уже свойство каждого отдельного человека. И очень важно чтобы статические методы не изменяли состояние системы в целом, не содержали побочных эффектов.
В статические методы можно выносить какую либо служебную логику. Например, метод перевода числа из арабской в римскую запись следует сделать статическим.

Есть ли у статического варианта какие-то подводные камни

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

Центральный показатель для бизнеса, а следовательно и руководителей, как людей представляющих интересы этого самого бизнеса - это коэффициент возврата инвестиций (ROI). Соответственно, сотрудник должен приносить компании больше денег, чем потребляет. Естественно, что чем выше разрыв между затратами и прибылью, тем лучше, поэтому фонд оплаты труда руководитель должен держать на том минимальном уровне, который гарантирует бесперебойную работу сотрудников. Один из факторов этой бесперебойности - низкая текучка. Сотрудников терять нежелательно. И чем ценнее для компании сотрудник, чем более он профессионален и/или чем больше на него завязано, тем дороже обходится его потеря. Натурально в деньгах. Придётся затратить больше, чем обычно, денег на поддержание работы без него. Придётся затратить деньги и время (те же деньги) на поиск, найм, введение в работу, возможно, обучение нового сотрудника. При этом он может оказаться совсем неподходящих и цикл придётся повторить. Или может оказаться просто хуже прошлого и эффективность отдела снизится. Поэтому, когда сотрудник приходит просить прибавку, руководитель оценивает может ли этот сотрудник уйти или только блефует, насколько легко его будет заменить, какой урон компании будет нанесён его уходом. Потом руководитель оценивает стоимость расширения ФОТ - есть ли резервы, какой сейчас ROI, будет ли больший ROI от реинвестиции этих средств во что-то другое? Если уход сотрудника будет стоить меньше, чем увеличение ФОТа, сотруднику откажут.

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

Из этого вывод, стратегия проста - увеличивайте собственный профессиональный уровень на столько, чтобы свободно менять компанию, как только вас что-то перестало устраивать.

Я работаю с MongoDB на протяжении уже 4х лет. Имеется ряд проектов, созданных как с использованием этой БД, так и использованием классических RDBMS.
MongoDB это не MySQL и не PostgreSQL. Большинство людей пытается сравнить оба типа баз данных, но это абсолютно глупо и неприемлемо. Это все равно что сравнивать врачей и инженеров.
MongoDB подойдет там, где нужна гибкость структуры и большие объемы данных. Например хранение истории болезни пациентов в масштабе страны. Каждая карточка может быть разного типа со множеством полей. И их могут быть триллионы. Для классических реляционных БД это выливается в весьма нетривиальную задачу горизонтального масштабирования, которая в MySQL решается через перенастройку сервера, а в PostgreSQL через специальную промежуточную таблицу. Горизонтальный рост и ввод новых узлов кластера сопряжен с большими трудностями и плохо автоматизируется для реляционных БД.
Еще классические БД очень плохо работают со смешанной нагрузкой, когда у вас запись/чтение примерно 1:1 и данных очень много. Это вызывает непрерывное перестроение индексов и их использование больше мешает. Это тот тип нагрузки, при которой InnoDB частенько повреждается без возможности восстановления или что вызывает значительный простой на реорганизацию структур данных.
Также существует очень много задач, для которых использование MongoDB исключительно неприемлемо. Если вам необходимо работать с нормализованными данными - используйте реляционные БД. Если нужна мощная аналитика - колоночные. Разумеется, каждая из этих опций имеет свою цену.
На рынке нет универсального решения. Каждое заточено под свои задачи.

Я расскажу Вам про личный опыт, без претензий на истину в последней инстанции...

Для чего идеальна MongoDb? Примеры приложений, где монга будет лучше mysql?

Для человека который привык работать с реляционными БД, смириться с логикой и вообще с подобными БД - довольно сложно. Для тех, кто работает с реляционными БД профессионально - сделать это ещё сложнее...

Если сравнивать с реляционными БД и с оглядкой на конкретно MySQL - монга идеально вписывается там, где структура данных заранее неизвестна. Тут я хотел привести пример, но не смог придумать ни одного дельного примера, после того как начал плотно работать с PostgreSQL... Давайте попробую из практики. Мы один раз применяли монгу в проекте где есть десятки и сотни тысяч товарных позиций и у каждой из них свой уникальный набор различных свойств. На основе уже имеющихся свойств, "соседних" товаров, контентщику предлагался наиболее вероятный набор параметров, которые нужно заполнить, но в любой момент он мог удалить или добавить любое поле и/или множество значений одного из них, например, "Цвет: черный, серый, фиолетовый". Всё это дело попадало под разные динамические фильтры и далее по цепочке... В то время, насколько я помню ещё не было поддержки JSONB-формата у PostgreSQL, по этому мы остановились на MongoDB. Ну и конечно же, желание "воткнуть ультра новую и модную БД в проект" сыграло свою роль...

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

Безусловно, не редко можно встретить проекты в которых даже в реляционных БД не прописаны, например, внешние ключи и контроля целостности данных как такового нет, но обычно это происходит по следующим причинам:
1. Очень низкая квалификация администратора БД проекта
2. В попытке выжать из базы больше производительности, не найдя других методов оптимизации
3. Данных настолько много, что БД/ключи - начинают "сыпаться", не редко это связано с п.1

Так же, последние тесты показывают, что PostgreSQL почти не уступает MongoDB даже в её родной среде (на уровне данных в формате JSON). А в некоторых аспектах даже превосходит её... Подробности Вы можете увидеть на некоторых конференциях по Postgres (да, на конференциях по MongoDB, Вы вряд ли увидите, как кто-то будет рассказывать, что [их любимая] монга "хуже" некоторых других движков...). Кстати, поддержку формата JSON стандартизировали (наконец-то) на уровне SQL-стандарта (если я не ошибаюсь) и в самом ближайшем будущем, думаю стоит ожидать полноценную поддержку оного в SQL-базах, в т.ч. поддержку в бинарном виде с возможностью индексации данных (кстати, некоторые SQL-базы уже такое умеют).

Моё понимание, ответа на вопрос, "когда действительно стоит использовать MogoDB?" звучит примерно так: Исключительно в тех случаях, когда Вы понимаете, что она станет действительно хорошим решением для поставленной задачи и сейчас и в будущем. В моей практике, таких проектов можно было бы насчитать ничтожно мало, а точнее около нуля, особенно с учётом развития некоторых современных SQL-БД и вообще направления "JSON в SQL" в целом. Но, безусловно такие проекты могут быть и есть (в данном случае, не у меня). Но, тут стоит обратить внимание на крайне важный факт - когда всплывает такой проект, что бы адекватно оценить наиболее оптимальную БД под него - нужно знать как минимум пару-тройку SQL-БД, со всеми их особенностями, достоинствами и недостатками... причем не просто "знать", а хорошо знать, "изнутри". А так же знать все характерные черты монги, а так же её особенности, достоинства и т.д. То есть, если Вы задаётесь вопросом, "а хорошо ли впишется монга в проект N?" и не можете найти на него однозначного ответа, вероятнее всего, что в долгосрочной перспективе, в "проект N" она впишется плохо.

P.S. В заключение, хочу ещё раз напомнить, что "JSON в SQL" - активно развивается... Со всеми вытекающими.

Здесь плохо всё, к сожалению.

Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

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

$result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

?

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

Зачем вы используете свойства, если можно обойтись обычными локальными переменными:

$this->orderID = (int) strip_tags($orderID);
$this->column = (string) strip_tags($column);
$this->value = (string) strip_tags($value);

?

Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
strip_tags($orderID);
?

Если вы не используете php 7 и, как следствие, скалярный тайпхинтинг, то должны делать проверки на тип входящего аргумента. Если что-то не так с типом, бросаем исключение (А не приводим его к нужному)! Например:

if (!is_string($arg)) {
    throw new InvalidArgumentTypeException('string', $arg);
}

Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

Кроме всего прочего, почитайте про стандарты оформления кода. Вы им не следуете.

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

Желаю успехов!

У вас скромный рейт. Хотя, возможно, для Чехии это нормально.

Я работал и работаю на фрилансе уже много лет. И в штате много лет тоже работаю.
Поэтому могу кое-что сказать.

Минусы

1. Все байки про фриланс — правда.

2. Нужно иметь железную дисциплину, чтобы работать в строго отведенные часы, а в другое время отдыхать. И чтобы вставать вовремя, а не спать до обеда.

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

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

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

6. Хорошее описание проекта, хороший продукт сам по себе — на фрилансе этого мало. Повезет, если получится удаленно вписаться в команду, которая делает или большой проект или делает много проектов на потоке. Если же это разовые проекты, то будь готов к задаче вида "ну мне вот сайт нужен с формой, сообщениями и робокассой, а ну вот еще там корзина, да".

7. Забудь про стабильность. Сегодня ты заработал двойную зарплату, а в следующем месяце процентов 50. Нет никого, кто строго раз в две недели будет тебе перечислять деньги на карту.

Плюсы

1. Свобода в выборе задач и проектов. Это прям кайф.

2. Есть возможность заниматься своими делами, потому что за проекты отвечаешь ты и только ты. Соответственно, можно брать выходные, когда тебе удобно, а не когда они на календаре пришли.

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

4. Есть возможность учиться. Не вечером после работы, днем, когда голова свежая.
Офис эту возможность сильно ограничивает.

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

Где работать
Попробуй везде. И на фл и на апворке есть свои плюсы и минусы.
Но самые лучшие клиенты — это, конечно, которые приходят напрямую.

Лучшее объяснение Redux что я видел.
getinstance.info/articles/react/learning-react-redux