В каждой команде есть свои правила оформления кода, тестовых заданий это не должно касаться. Это тест на знание кода и формирование логики претендента.
На что тест - знает только работодатель и не вам ему указывать Раздрай в оформлении кода часто гораздо более важный показатель, чем алгоритм, ибо это потенциальный рассадник ошибок. Важно не то, какой стиль, а его наличие. Хотя в моих глазах использование PSR - преимущество.
PHP для Windows не поддерживает работу с UTF16 именами файлов (NTFS использует UTF16). По-этому, вы можете работать только в рамках текущей локали windows (cp1251, например).
То есть так или иначе "кракозябры" будут получаться на выходе? А какое возможное решение? Возможно ли, например, использовать python чтобы все имена папок потом сконвертировать в utf-16 и переименовать в нормальный вид? Или можно как-то по-другому решить?
А какие у вас задачи? Именно, что бы на диске было красиво? Извернуться то как-то с переименованием можно, но будет другая проблема - читать вы такие директории не сможете.
Если задача выдавать что-то красиво в админке, то хранить имена в базе, и соответствующий путь на диске.
Ну или iconv c //IGNORE и смириться с потерей всяких странных символов
PHP для Windows не поддерживает работу с UTF16 именами файлов (NTFS использует UTF16). По-этому, вы можете работать только в рамках текущей локали windows (cp1251, например).
Опыт набирать нужно в командах. Участвуя в разных проектах с хорошими лидерами. Если сидеть одному на фрилансе и пилить разные проекты - опыта не наберешь, скорее наоборот.
Программист - профессия, связанная с экстремальным расходованием жизненных сил. 55 деревянных? Не стоят, имхо, указанных требований.
Вдобавок, о каких 5/2 может идти речь, когда данную профессию выбирают, чтобы почти не ходить на работу?!
40-60 в принципе нормальная з/п для junior-а. С опытом от 0 до года.
Ну т.е. люди, которые знают PHP, но не умеют программировать.
Видимо, такие им нужны.
Ясно дело, что если человек не баран, через годик такой работы он спокойно пойдет на 60-80, а через пару - до 100.
1. Подзапрос тут не нужен вообще
2. Сортировка в подзапросе не обязана оказывать влияние на сортировку основного запроса
3. При использовании группировки в выборке могут быть только те поля, которые участвуют в группировке, а все остальные поля только внутри агрегирующих функций.
На самом деле тут непонятная вакансия, даже интересно.
Если перечисленное нужно знать, что бы контролировать работу команды - это вакансия, скорее, CTO. Тогда не понятно, где требования об организации работы и в какой-то мере управления проектом.
Если делать все самому - то тут три направления: сервер, клиент, верстка. Senior-ов одновременно во всем не бывает, ибо просто не хватает времени постоянно мониторить все области не с точки зрения расширения кругозора, а с точки зрения профессионального применения.
Если нужно все, но на уровне "чота могу сделать", то это не senior точно. Хотя тогда з/п завышена сильно.
В этом случае пострадали бы все нормальные программисты, которые используют метод с названием класса. Запрещать такое из-за обратной совместимости было бы верхом идиотизма.
А вероятность такого события много меньше, чем и так ничтожная вероятность "прямого" порядка.
Да о чем спор ;) О пхп4 думать не нужно... нам не нужно, а вот разработчикам ядра пхп - нужно ;)
Т.е. рассматривается случай, когда есть кучу старого кода пхп4, который нужно запустить под пхп5. А такого кода, на самом деле, хватает даже сегодня.
И может такое случится, что в какому-то из этого кода кто-то использовал метод с именем __construct. И код при запуске в ПХП5 становится нерабочим.
Вот об этом и нужно предупредить того, кто этот код запускает, что может быть проблема. Вот этот стрикт по сути об этом. Он о том, что у нас два конструктора. А не о том, что у нас старый конструктор. Если просто взять класс со старым конструктором - никаких стриктов не будет в пхп5 https://3v4l[dot]org/Kjsbo