@tsflight @Eraice http://www.phptherightway.com/

Здравствуйте. Хочу научится кодить на пхп. И в будущем работать веб девелопером. Какие материалы посоветуете? И есть ли сайт с заданиями(проектами) для практики реальной пхп разработки. Спасибо.

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

нужно учиться критически воспринимать любую найденную информацию

Здравствуйте. Хочу научится кодить на пхп. И в будущем работать веб девелопером. Какие материалы посоветуете? И есть ли сайт с заданиями(проектами) для практики реальной пхп разработки. Спасибо.

возможно чем-то поможет https://toster.ru/q/459859

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

нет смысла брать фреймворк если ты не знаешь php, так же нет смысла брать фреймворк если ты не понимаешь концепций лежащих в их основах

можно задачки более мелкие генерить, например "напиши свою примитивную СУБД на PHP"

зандстру по ссылке засирают...

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

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

иначе последовательность обучения будет нарушена и часто это приводит к задержкам в понимании

я 2 раз буду перечитывать)

я много людей знаю которые хватались за паттерны и лишь через 2 года понимали что "наверное я что-то упустил"

а сколько было людей которые пытались все эти паттерны запихнуть куда не следует, ух

а ты что посоветуешь?)

мне надо знать уровень того кому я советую что бы что-то дельное вышло

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

когда массив объектов

базовые знания/понимания)

или коллекция

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

- массивы/списки/коллекции - объединение типов - пояснения что "это не просто строка а крутая строка"

это да, ок

Что нужно знать, чтобы взяли джуном в Intellectsoft ?)

хотя объединения типов все меньше

а ты что посоветуешь?)

я могу лишь перечислить проблемы у людей, в том числе и свои: - очень поздно к людям приходит понимание что код чаще читают чем пишут - очень поздно люди учатся писать тесты, хотя на начальном этапе обучения это как раз таки очень сильный профит будет давать - Часто люди не пониманиют принципов разделения ответственности, не умеют в декомпозицию (не потому что несдюжили а просто потому что не пытались даже разобраться) - Очень часто люди даже не пытаются разбираться с понятиями которые они где-то увидели/услышали. Не любят искать первоисточники. Например увидали очередную статью школьника что "MVC есть такой где M это база данных" и пошли ваять свои детища не разобравшись. Про инкапсуляции всякие и полиморфизмы я вообще молчу. Заучить определение для собесов и на лет 10 хватит

Что нужно знать, чтобы взяли джуном в Intellectsoft ?)

стань мидлом тогда поговорим

до мидла далеко)

http://composingprograms.com/

вот еще есть подобные штуки для обучения

ну либо тот самый SICP почитать...

хоть будет тяжелова-то

хотя и composing programs хорошо структурированный материал для начинающих кто хочет более-менее последовательно вещи изучать

например там есть прям даже про дебаг неплохой материал и этому там учат. Большинство же методом проб и ошибок это делают

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

ну короч... ладно, это такое...

в закладки добавил)

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

https://www.amazon.com/Linux-Command-Line-Complete-Introduction/dp/1593273894/ я вот эту книгу щас читаю, советую кстати для новичков хотя бы часть прочитать

обложка огонь

а подробнее про адаптивные/эволюционные подходы? я сейчас уперся в чужой код, в котором напилено и нагорожено столько всего, что временами больше часа сидишь и разбираешься на кой все это было запилено/задумано

адаптивный подход - написание неких адаптеров к старому коду?

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

и как результат?)

недавно вроде отговорил таких товарищей

адаптивный подход - написание неких адаптеров к старому коду?

нет, это "пишем код 15-20 минут, и сразу минут 5-10 прибераемся

а то у нас был уже такой проебанный проект

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

за 3 месяца

не отрываясь особо от основных задач

а подробнее про адаптивные/эволюционные подходы? я сейчас уперся в чужой код, в котором напилено и нагорожено столько всего, что временами больше часа сидишь и разбираешься на кой все это было запилено/задумано

адаптивные/эволюционные это когда ты не сразу делаешь хорошо а делаешь хорошо постепенно. Ну мол идея в том что "сразу сделать хорошо можно только если ты когда-то уже делал то же самое"

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

а подробнее про адаптивные/эволюционные подходы? я сейчас уперся в чужой код, в котором напилено и нагорожено столько всего, что временами больше часа сидишь и разбираешься на кой все это было запилено/задумано

почитай Рефакторинг Фаулера. Еще есть мысли - нашел кусок кода который непонятно что делает, дай ему имя, может быть неверное, и потом уточняй по мере того как разбираешься. Ну и еще хорошая мысль - разобраться в том что есть temporal coupling, чем оно плохо и научиться его устранять. Ибо это одна из основных вещей которые мешают рефакторить.

https://www.amazon.com/Linux-Command-Line-Complete-Introduction/dp/1593273894/ я вот эту книгу щас читаю, советую кстати для новичков хотя бы часть прочитать

не скучная?

не скучная?

не

ну и еще - приемочные тесты было бы нелпохо на легаси писать... end-to-end например

почитай Рефакторинг Фаулера. Еще есть мысли - нашел кусок кода который непонятно что делает, дай ему имя, может быть неверное, и потом уточняй по мере того как разбираешься. Ну и еще хорошая мысль - разобраться в том что есть temporal coupling, чем оно плохо и научиться его устранять. Ибо это одна из основных вещей которые мешают рефакторить.

чистый код Роберта Мартина не освещает этих подходов?

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

у Фаулера же больше рецепты как код уже имеющийся чиститиь

не важно писал ты код 10 минут назад или месяц назад, тут разница будет только в масштабах и понимании

"Рефакторинг" короч одна из must read книг

https://www.youtube.com/watch?v=XdENEr4gkTM

вот еще неплохой материал на тему работы с легаси

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

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

и это работает на любых масштабах. Большинство людят "четкое ТЗ" а потом зляьтся что требования меняются...

любят наворотить тонны ненужных фич вместо того что бы "побыстрее выпустить рабочий продукт"

ну и т.д.

"Рефакторинг" короч одна из must read книг

Вот еще ресурс к этому с примерами https://refactoring.guru/

это на самом деле естественный способ человека решать проблему - думать больше. Просто часто "думать больше" не приносит плодов, нужны эксперементы

лучше книгу почитать

она есть на русском, она не сказать что "устарела" - там все вполне четко

слушай

а вот по английскому

обязательно ли знать?)

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

обязательно ли знать?)

очевидно же, что знать надо, обязательно

intermediate

норм

обязательно ли знать?)

80% хорошей информации и документации на английском, прокачивай скилл)

обязательно ли знать?)

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

ну для начала..

в дальнейшем то понятно

обязательно ли знать?)

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

эмм, как бы уже работаю)

Ну тогда нужен, и очень сильно нужен.

Помню старый анекдот. - Скажите а как вы так быстро выучили Английский язык? - Да просто в нем половина слов из С++ заимствовано.

Помню старый анекдот. - Скажите а как вы так быстро выучили Английский язык? - Да просто в нем половина слов из С++ заимствовано.

Лалка

/stat@combot

combot.org/chat/-1001042383571

странно, а че меня в статистике нет

а хорошо когда активность малая или когда спама кучу пишешь?

определение спама субъективное.

бот не в курсе полезное твое сообщение или нет

В понедельник активность на 25% больше.... в понедельник никто не хочет работать :)

разбаньте @RmFloodUser и будет всегда активность, но какая!

определение спама субъективное.

Объективно

Объективно

разве что там ии или пару десятков модераторов которые кликают спам или не спам ?

Я о том, что можно почти всегда однозначно сказать, спам перед тобой или нет, а значит, объективно

разве что там ии или пару десятков модераторов которые кликают спам или не спам ?

вы флуд спамом называете?