jaxel

проблема понимания ООП на 90% - в плохих переводах которые делаются хрен знает кем и хрен знает как. зачастую люди вообще слабо понимают о чем пишут (переводят) либо у них проблемы с языком изложения.
либо авторы страдают неудержимыми приступами графомании.

почему-то мне кажется что все ООП можно изложить схематически на 3-х тетрадных листочках

Я сам изучал ООП на С++ (по страуструпу лет 25 назад), но парадигмы остаются такими же - наследование, инкапсуляция, полиморфизм.

а Dependency Injection - просто как мычание. "в объект при его создании (как правило при создании ) передаются объекты от которых он зависит"

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

Изучите scrum, agile, JIRA и идите в менеджеры IT проектов.

Коллеги, тут шла речь про "год, два, три"... Лично моё субъективное мнение:
1. Год полноценной работы в IT (программировании) - даёт (но не гарантирует) хорошую возможность устроиться в какую-нибудь конторку, пилить "сайты на Wordpress".
2. Года 2-3 - даёт возможность устроиться в контору посерьёзнее и возможно уже на должность "мидла", но только в том случае, если всего эти года 2-3 либо кто-то, либо ты сам - крайне плотно занимался своим обучением. Обычно это должен быть либо хороший наставник, либо хорошие психостимуляторы, что бы такое количество информации вбить в голову за года 2-3.

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

Год-два-три - это отличный способ устроиться на з/п в 15-40тыс. в редких случаях чуть больше, в пределах 1000$ обычно, при "нормальном" раскладе.

Дабы не быть голословно "обвиненным" в причастности к "клану школьников", два слова о себе. В IT без малого как 20 лет, решил пойти в IT лет наверное 30 назад :)) Работаю руководителем отдела разработки, а так же имею опыт работы в международных компаниях (не фриланс).

P.S. Если хотите, что бы я Вас отговорил от этой мало перспективной идеи, просто пообщаться (со мной или группой начинающих и не очень начинающих разработчиков сети/веб- направления), или поговорить о чём-нибудь ещё... - в моих контактах есть ссылка на группу, оттуда соотв. Вы можете написать и мне (лично), при желании.

У нас в городе, кол-во открытых резюме (по нашему профилю), по разным подсчётам варьируется от 300 до 800 (по разным подсчётам). А на работу нанимать некого, хотя чуть ли не у доброй половины написано, что стаж работы 5+ лет... Мне кажется, у многих, реальный стаж работы 5+ дней, судя по объёму знаний, с которым они приходят на работу устраиваться...

ЗП в 100К если и светит, то только через года 3-4, причем батрачить нужно днем и ночью. Если взять большинство профессий и вкладываться в них так как нужно вкладываться в программирование, то заработать на них можно и больше. У меня есть знакомый который в продажах (менеджером работает, кабеля, считки и прочую фигню продает), уже через 1 год начал зарабатывать больше, чем некоторые PHP сеньеры когда либо будут зарабатывать, поверьте мне, то что программисты много зарабатывают (что тоже спорно) - не просто так... Кстати, еще к слову, этот знакомый (который работает менеджером), когда приходит с работы играет в танки и смотрит сериальчики тупые, спросите любого прогера, что они делают после работы. Уверен большинство из них скажут, что они читают доки и кодят. Дальше думайте сами...

зп в 100 неспроста дается, 80% прогеров до 60 тащатся, среди них опять же 80% вообще до 30
хотя все ооочень индивидуально... судя по всему у тебя то точно все хорошо будет

в веб не иди, суеты много и миллионы библиотек и фреймворков, хотя одно и тоже делают, иди во взрослые языки (тот же C или Java/Kotlin)

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

php.net/manual/ru/book.intl.php
php.net/manual/ru/class.messageformatter.php
www.icu-project.org/apiref/icu4c/udat_8h.html#details

Причин много:
1. Бизнесу всегда нужно срочно. Из-за этого менеджер/заказчик бьет по рукам и говорит "не до архитектуры и главное быстрее", по итогу — пилятся костыли, которые блинным комом накатываются и в определенный момент нужно переписывать куски структуры, чтобы просто иметь техвозможность работать дальше
2. Если было жирно по ресурсами и времени изначально и такая проблема — не правильная архитектура, экономия на тестах и прочее
3. Плохая договоренность и плохое понимание задачи с каждой стороны, у кого-то завышенные/заниженные ожидания (один сказал сделай мне приложение, второй сказал, что сделает — вина обоих в таком случае)
4. Не всегда это плохо. Сначала быстро запустили (проверили гипотезу, получили первые деньги, инвестиции и прочее), потом переделывают планово (просто этот план может не проговорен, отсюда плохие ожидания и чувство низкого КПД, а он может высокий как раз).

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

UPD: Urukhayy речь не об этом проекте?
Может ли проект быть собран с низким качеством кода, и пользоваться большим спросом?

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

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

Не работайте с такими людьми. Сейчас, может, и нормально будет, но в следующий раз обязательно что-нибудь случиться.

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

Он может поставить проект на паузу или вообще пропасть — предоплату-то не вносил, поэтому пофиг.

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

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

По вашему вопросу — никак. Код доступен всегда. Можете напихать в JS какого-нибудь говно-кода, который будет тянуть с удаленного сервера ваш скрипт, в который можно будет подсунуть любую бяку — замедлять загрузку сайта, например, или вообще затирать весь хтмл. Но это же не вернет вам денег. Да и легко правится простым удалением нужных строк в js-файле.

Есть стандарт UUID. На его основе сделайте свой.

AAA (Authorization, Authentication, Accounting, не имею в виду семейство протоколов, а саму идею) - это всегда отдельная тяжелая служба, потому что высокая связность и зависимость других служб не входят в парадигму микросервисов.
Лучше всего себя показывает такой подход (AWS IAM, фейсбучная проверка доступа, тысячи их): отдельный сервис для работы с ACL, непосредственно контроль доступа - на стороне микросервисов.
Формат ACL можете честно стырить у IAM: на каждый тип объектов - базовые active,owner,read,edit и присущие этому типу, все ID объектов в одном формате и биективны, записи по каждому виду доступа в двух видах: Permission - ID (например для владельца) и Permission - ID List.
Непосредственно контроль доступа - на стороне микросервисов без выноса в отдельные сущности. Доступ проверяется по ID объекта, инициализирующего действие, по надобности ещё проверяются и его группы.
На вашем примере: PatientTHX1138, врач DoctorMengl создает карту о визите Case23523 и анализы Test991235-991237. У каждого анализа есть права на чтение/изменение всех его данных (для пациента/его лечащих врачей) или только даты приёма, кабинета и проводящего врача (для ресепшна). Дело передаётся отдельной функцией путем замены в ACL владельца, предыдущий врач в зависимости от причины передачи либо лишается доступа (увольнение/отстранение), либо получает доступ на чтение в обычном случае передачи, либо получает доступ на запись в случае передачи внутри группы врачей. Аналогичная ситуация с разным уровнем доступа для врачей и ресепшна у самого визита и пациента (ресепшну вряд ли надо знать, какого размера камень в почках).

Начните с книги М.Зандстры про PHP. Очень ёмкая и подробная книга, охватывающая много аспектов. На мой взгляд это лучшая книга по PHP.
Ну и порешай к задачки на codewars немножко, чтобы руку набить на простейших вещах

Не уверен, что даю верный совет. Но я бы начал с изучения ООП (если еще нет глубоких знаний в этом) и какого-нибудь фреймворка, как минимум будете понимать MVC.

Понимать что там происходит на фронте + минимальные знания точно будут нужны.
Сам из таких, фронт не люблю.