Максим Федоров

Что значит красиво?

Можно просто взять
echo implode(PHP_EOL, $randArray);
И каждый элемент выведется с новой строки (между ними будет перенос строки).

Для верстки понятно, что работать не будет, там уже используйте
echo implode('<br>', $randArray);

Можно выводить в цикле

foreach($randArray as $item) {
  echo $item;
}

2. echo не работает для массивов, выводится "Array"

Добавлю ко всем ответам выше
Не нужно ничего учить! Это бесполезно! Практика, практика и еще раз практика, а когда уже на практике что-то встречается, то исследуем и снова практикуемся

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

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

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

Как вы это делаете?! За 17 лет работы в ИТ у меня ни разу не возникало вопроса "Куда двигаться?", только "Где взять времени на освоение всего этого бесконечного изобилия технологий, углублённого изучения уже знакомого и реализацию множества идей?"

Мало данных про архитектуру. Почему на PHP не хватает производительности? Что именно жрет ресурсы? Можно ли это оптимизировать?Какие узкие места в приложении? Лучше ответте сначала на вопрос, чего не хватает сейчас в PHP , а потом смотрите/спрашивайте чем заменить - highload очень разный. Лучше использовать тот инструмент, которым вы хорошо владеете.

Высоконагруженные facebook и vkontakte живут на php.

Проблемы не в языке а в умении им пользоваться правильно

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

ИМХО, Lumen это высер обиженного Тейлора после теста на производительность, он взял и поубирал вовсе или в ифы часть laravel. Мой опыт общения с подобными фреймворками подсказывает что рано или поздно придтся тащить остальную функциональность, поэтому лучше иметь сразу готовый фреймворк, слава богу с x64 и гигами оперативки можно уже на заморачиваться микрооптимизацией.

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

Всё, я добился своего.
Мой скрипт запускался под пользователем, у которого нет прав (www-data).
Чтобы скрипт запустился, я установил модуль sudo и в его конфиге (visudo) добавил строчку: www-data ALL=NOPASSWD: ALL
Перед самой командой я теперь приписываю sudo -S и она отрабатывает.

Если нужны адреса по России – посмотрите https://dadata.ru/api/detect_address_by_ip/

Вопрос довольно каверзный, так как имеет несколько путей решения.
1) Можно сместить сроки (Они смещаются даже на самых дорогих и страшных проектах где казалось нельзя ничего сместить. Нужно лишь правильно аргументировать...);
2) Можно посадить помощь в пару (Ваш "запоздалец" будет излагать задачи и будет подсказывать по архитекутуре и логике проекта, а "новый" свежим взглядом окажет помощь. Помогает всегда, вопрос лишь в реалиях уложится конкретно в 1 день, если там трудозатрат на 3 дня. Тут уже надо подключать больше людей. Лишь бы хватило компетенции поделить задачу на это количество людей)
3) Упростить задачу (наверное, самое простое и применяемое на практике решение. Если по бизнесу задача критична, то её можно довыписать в доделку. Важно уловить на чем разработчик завис и постаратся эту сложность срезать но обеспечив задаче "сдачу" по требованию хотя бы в минимально подобном виде)
4) Перенести дедлайн (дедлайн он чем то обусловлен. релиз, показ, тест, либо же стопер для другой задачи. ну если речь про джуна, то необходимо избегать поручения зависимых задач на джунов. ну а если отойти от уровня и говорить о дедлайне, то можно исключить задачу из релиза или показа. Частенько такое практикуется. Ни кто пока от сотрудничества не отказался. Чаще всего на сдаче крупных годичных проектов у нас 5-15% требований не сделаны к релизу до конца и в него не включены. Да, кланяемся, извиняемся, работаем ночами но это все равно решение лучшее когда другое уже не поможет)

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

Ресурс должен работать! Каким бы галимым он не был. Если издержки перевешивают профит от ресурса, то да, следует выгнать. Чаще всего, издержки мизерные. Нужно лишь правильно это построить.

Если речь о джунах, то я открыто им говорю, что рынок не может платить им зарплату за такую скорость решения задач, качество и т.д. и если они хотят удержатся на этом рынке, то пускай работают сколько им нужно (час после работы, два, три - ночь, выходные) пока не научатся и не сорганизуются так, что бы укладыватся во время. Чаще всего люди склоняют голову и работают после работы, дома, на выходных. Большинство справляется. Месяц, второй и получается вписыватся в нужные сроки.

С некоторыми даже происходили невероятные метаморфозы из-за этого. Кто то перестал курить по 15 раз на день бегая на балконы с кофе. Кто то перестал читать ленты вконтакте и лайкать смешные видео. И не пришлось никого наказывать или ставить жуткие правила в офисе. Сверхурочная работа выбила дурь из людей и они ходят с 9 до 18 что бы делать работу не показывая головы из неё пока не сделают.

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

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

Адекватный джуниор не должен ПРОСТО сидеть и не успевать в срок.

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

В этом заключается разница между чайником и ламером, между адекватным человеком, который со временем вырастет, и тем, за которым ВСЕГДА придется бегать.

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