Как стать автором
Обновить

Комментарии 190

Хотели бы мы взглянуть на ньюба, кто осилит не то что выучить, а хотя бы полностью понять всего за
Месяц 1
вот эти две вещи
ООП и паттерны — ozon.ru
Совершенный код — ozon.ru
Подразумеваем, что на входе у нас не совем неофит, а более-менее опытный, просто писал модули для джумлы работа не мотивировала развиваться.

Выучивать не надо, нужно хотя бы раз прочитать, чтобы потом знать, куда копать. Если читать по 100 страниц в день, то это как раз на месяц.
Если читать на работе — а обучение — это рабочая активность — то да. А если вечерами и на выходных — то забудьте про сто страниц в день. Особенно учитывая, что англоязычную литературу (типа того же МакКоннела) лучше читать в оригинале.
Можно узнать, чем это лучше читать в ортгинале?
В переводах есть ошибки и терминологическая путаница. Переводы выходят (иногда очень сильно) позже. Наконец, это полезно для развития навыка, который, в свою очередь, нужен для того, чтобы читать то, что вовсе не переведено.
Можно узнать, чем это лучше читать в ортгинале?
Из-за потери информации при переводе, касается (разумеется) не только программирования.
Неплохая картинка «почти на тему» s1.static.gotsmile.net/images/2010/09/25/5427.jpg_1285441526.jpg — слева считайте текст в оригинале, справа считайте текст в переводе.
При чем даже если человек знает английский ниже среднего, в оригинале он получит больше информации, т.к. в переводе будет передан только один из возможных смыслов исходника, при чем с потерей нюансов (которые как раз иногда и важны).

При этом технические книги, в большинстве своем, достаточно однозначны в оригинале, проблема именно в точном переводе, поэтому в отличии от художественной литературы порог вхождения в технический английский намного ниже.
Приведу свои вечные примеры:
В книжке про паттерны pseudo-UML перевели как Псевдо-XML (ну правда, какая разница)
В книжке по iOS разработке было выражение «неподписанное целое». Догадываетесь что было в оригинале?
В книжке CLR via C# целыми предложениями вырезали перевод. Я читал в оригинале, но обращался к переводу пару раз ради этих самых предложений (сложное построение, смысл был не очень понятен). Видимо у переводчиков тоже возникли проблемы с пониманием, и они решили просто опустить эти сложности.
ну я когда-то давным давно читал по русски учебник, плевался и читал в оригинале.
Сейчас я читаю перевод, если он ок, но помню что могут быть ошибки и ляпы, и при сомнениях открываю оригинал.
Мой уровень позволяет читать оригинал, но блин это дольше, и часть сознания отвлекается, медленнее понимаешь…
Нет смысла просто. Если ты из учебника пропустишь 10% материала из-за перевода, то на фоне того, что реально воспринимается всего около 10-20% и не заметно… Справочники да, там часто проще читать оригинал. Там важна точность, и текста относительно не много за раз читаешь.
Держал (в Доме Книги на Полянке) недавно в руках Котерова, толстая такая книженция. Почудилось, что книга написана очень хорошо.
В моей личной библиотеке есть экзепляр. Ей убить при желании можно)
Не согласен. Работодатель платит вам зарплату за текущие компетенции и опыт, а не за что вы будете учиться в рабочее время.
Это плохой работодатель, хороший же, наоборот, заинтересован в развитии своих сотрудников
Нормальный.
Работник должен заниматься учебой в учебное, а не рабочее время.
Выделяет ли работодатель это учебное время — это отдельный вопрос.
Но учиться в рабочее время — это некорректно.
Это, если не секрет, какая статья ТК РФ?
Статью можно найти, при желании.
Статья 81, пункт 5.
5) неоднократного неисполнения работником без уважительных причин трудовых обязанностей, если он имеет дисциплинарное взыскание;


Система ГАРАНТ: base.garant.ru/12125268/13/#ixzz3cxzZPxFt

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

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

Что вы планируете делать с 81 п. 5, мне вообще не очень понятно. Впишете в должностные обязанности получение дополнительного образования? Во-первых, выхлоп юридически сомнителен (вы не можете требовать от сотрудника освоения новых навыков), во-вторых, вам придётся вписать это образование в 40 рабочих часов в неделю.

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

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


Простите, «идут на встречу» и «по собственному желанию» — это было бы оксюмороном, если бы не относилось исключительно к случаям, когда у компании есть шансы уволить сотрудника по статье. Тогда ему идут навстречу (а на самом деле — избавляют себя от огромного геморроя правильного оформления увольнения по статье) и предлагают написать «по собственному», надеясь на то, что он сам всё понимает.

Всё прочее — это не «навстречу», а банальное психологическое давление на сотрудников, плохо знающих ТК РФ и правоприменительную практику по нему.
Впишете в должностные обязанности получение дополнительного образования? Во-первых, выхлоп юридически сомнителен (вы не можете требовать от сотрудника освоения новых навыков), во-вторых, вам придётся вписать это образование в 40 рабочих часов в неделю.

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

Просто вы неоднозначно задали вопрос, простите. Отвечала на тему, как заставить человека работать, не я одна не поняла, заметьте)
Проще. Ежегодная (ежемесячная, ежеквартальная) аттестация


Я напомню исходный тезис, дополненный в комментариях: работодатель как бы хочет, чтобы сотрудник осваивал новые высоты, но «нормальный» работодатель на это рабочего времени выделять не обязан (второе — тезис не исходного текста, а некоторых комментариев).

Так вот, если работодатель хочет, но не обязан — то никакими аттестациями он сотрудника заставить что-то изучать не сможет.

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

Соответственно, законных пути у вас тут два — либо вы копаете от 195 ТК РФ и до обеда, устраивая полноценные курсы повышения квалификации, вписывая это в коллективный договор и т.п., либо все эти аттестации могут влиять только на премии и продвижение по службе. Увольнение по их результатам незаконно.
Аттестация обязана соответствовать должностной инструкции сотрудника, что возвращает нас на позицию номер 1. Вы не можете просто так завтра проаттестовать сотрудника на требования, которым он не был обязан соответствовать в момент приёма на работу три года назад.

1. Трудовой договор не обязан быть заключен на 5 лет или неопределенный срок.
2. Статья. Сокращение штатов (должность php-junior у нас больше нет, только php-middle). Предвижу ваши споры, однако определитесь, вы хотите юридического ответа, или практики в России или ...?
Так вот, если работодатель хочет, но не обязан — то никакими аттестациями он сотрудника заставить что-то изучать не сможет.

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

И прошу, в ответе, определитесь, мы говорим об юридических возможностях или практических. Юридически все статьи дееспособны: и срочный трудовой договор, и увольнение за неисполнение, и сокращение штатов, и прогулы (жесткий метод).
1. Трудовой договор не обязан быть заключен на 5 лет или неопределенный срок.
2. Статья. Сокращение штатов (должность php-junior у нас больше нет, только php-middle)


Это всё клёво работает, пока рынок неконкурентный, а сотрудники неграмотные. Как только эти два препятствия устраняются — вам, во-первых, придётся объяснять сотруднику, чего это у вас трудовой договор временный, а во-вторых, понимать, что либо он вас будет очень любить, либо по собеседованиям начнёт ходить месяцев за 5-6 до истечение договора.

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

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


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

Не обязан. Но только если ему дополнительно обученные сотрудники не нужны.

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


Формальная юридическая валидность без практической применимости не имеет смысла.
Формальная юридическая валидность без практической применимости не имеет смысла.

Вы спросили именно юридическое основание, без условий про «конкурентоспособность» и т.д.
А практика не обязана быть юридически идеальной, а суть вопроса была в том — существуют ли способы заставить человека учиться, я считаю, я достаточно привела аргументов, что существуют.
Это, если не секрет, какая статья ТК РФ?
Не поняли вопроса. Вы спрашиваете какая статья ТК РФ заставляет работника работать в рабочее время, а не сидеть вконтактике или писать диплом?
Честно говоря не знаем, но уверены что такая есть:)
Нет. Какая статья ТК РФ вводит понятие «учебное время». Потому как если не вводит — то обучать сотрудников надо будет в рабочее время, а всё прочее — бессодержательная игра слов.
Откровенно говоря мы не знатоки ТК РФ.
Но в свое время нас посылали от фирмы на курсы за ее счет, а до этого от учебного заведения как преподавателей на повышение квалификации, была и отчетность по посещению и результирующие экзамены и премия за результаты. И все это оформлялось вполне официально.
Это конечно было давно, но нам представляется логичным, что сейчас какие-то аналогичные варианты остались.
Повышение квалификации — это 195-197 ТК РФ. И помимо того, что не всякий работодатель захочет это оформлять официально (порядок проведения соответствующих мероприятий, например, должен быть вписан в коллективный договор), там есть ещё всякие расплывчатые подводные «но» типа обязанности работодателя обеспечить условия для совмещение работы и учёбы.

Всё остальное «на курсы за свой счёт» — либо в рабочее время, либо с оформлением как командировки, либо сотрудник имеет право на эти курсы радостно забить.

Короче, к «а давай ты выучишь книжку на выходных» это всё не имеет ровным счётом никакого отношения.
Точно так же для работодателя некорректно ожидать, что работник должен учиться навыкам, необходимым этому работодателю, вне рабочего времени.
Значит, работодатель попросту не заинтересован в повышении компетенций сотрудника — и должен рассчитывать, что, повысив их самостоятельно в свободное время, он уйдёт к другому работодателю.
Причем тут не заинтересован? Если сотрудник в свободное время качается с джуниора до мидла — он получает другую должность, оклад и, например, единовременный бонус за level up. Но по моему мнению, обучение должно происходить именно в свободное время.
Очень редкий работодатель может позволить себе платить стипендии для текущих работников. А оплата за хорошее обучение — это именно стипендия.
То есть этот работодатель не заинтересован в повышении моей квалификации? Ну а я не заинтересован в таких работодателях, все симметрично.
Да, мы тоже бы хотели, что бы нам платили зарплату за то что мы обучаемся.
Но почему-то работодатель требует работать за деньги, а за обучение почему-то приходится выкладывать свои.
Такой несправедливый мир:)
Ну, во-первых, как ни странно, зарплату вы получаете в том числе и за обучение (если вы не узнали на работе ничего нового — может быть, вы не там работаете?). А во-вторых, хороший работодатель заинтересован в том, чтобы его работники повышали свою квалификацию — и, как следствие, и в их прямом обучении. У нас в свое время и книжки оплачивали, и курсы, и конференции.
хороший работодатель заинтересован в том, чтобы его работники повышали свою квалификацию
Не всегда.
Вообще бизнесмен заинтересован что бы его работники росли только в том случае, если его бизнес как минимум с той же скоростью, с которой растут его работники. Но работники-то как правило растут быстрее бизнеса (если они не идиоты и это не какой-то удачный стартап).
Куда девать 5 новых миддлов выросших из джуниоров, если для них нет вакансий? Выплачивать пособие и отпускать на волю? А потом выплачивать денег хеадхантерской конторе за найм 5 джуниоров?
Куда девать 5 новых миддлов выросших из джуниоров, если для них нет вакансий? Выплачивать пособие и отпускать на волю? А потом выплачивать денег хеадхантерской конторе за найм 5 джуниоров?

А зачем вам пять джуниоров? Что, пять мидлов не могут выполнить их работу? Могут, и — обычно — лучше (по тем или иным показателям). Или пять мидлов для вас не окупаются?
С такой логикой вообще ни к чему нанимать «1 сеньеров, 3 мидлов и 8 джуниоров изначально». Надо сразу нанять 12 сеньеров и потом размышлять о том, что они вполне могут выполнить работу 1 сеньера, 3 мидлов и 8 джуниоров при этом лучше и окупиться:)

Фирма изначально нанимала 1-3-8 (1 сеньер, 3 миддла, 8 джуниоров) команду, если в фирме не дураки (а это подразумевается, ведь руководитель у нас хороший, не так ли), то они знали и понимали что делают и наняли адекватную для решения задач команду и команда «4-12-0» их задачам не отвечает (иначе бы они ее и наняли).

Это знаете, есть анекдот такой. «Почему жена десять лет усердно старается изменить мужа, а потом жалуется, что он не тот человек, за которого она выходила замуж?.»
Я вот ни разу не видел, чтобы можно было точно оценить, что нужно именно столько миддлов и джуниоров. Обычно оценки разбросаны между некоторыми границами. Более того, очень часто на момент набора на рынке нет нужных специалистов, и берут других (мотивация разная). В-третьих, есть компании, у которых достаточно заказов, но не хватает ресурсов. И вот тут рост разработчика приносит пользу — можно брать больше заказов и получать больше прибыли.

Наконец, в-четвертых, рост разработчика — штука неизбежная (если это хороший разработчик, а зачем вам плохие?). И вы все равно рано или поздно окажетесь в ситуации, когда у вас квалификационный состав команды не совпадает с тем, который вы нанимали.
Я вот ни разу не видел, чтобы можно было точно оценить, что нужно именно столько миддлов и джуниоров. Обычно оценки разбросаны между некоторыми границами
Так в границах и проблема.
Если персонал обучить, то количество джуниоров может упасть ниже границы, а количество миддлов подняться выше.

И вот тут рост разработчика приносит пользу — можно брать больше заказов и получать больше прибыли.
Если не хватает сеньеров — их можно нанять. Это намного быстрее чем обучать. И зачастую разумнее.
При чем «больше заказов» с ростом разработчика Вы фиг возьмете, т.к. у Вас будет 20 начальников (сеньеров), но не будет пехоты (джуниоров) — и все равно придется идти на биржу, только за другим контингентом.
Да и лояльность выращенного сеньера не просто не гарантирована, а напротив — практически гарантирована нелояльность. Потому что умный и любознательный разработчик не захочет застрять до пенсии в одной компании.
Если персонал обучить, то количество джуниоров может упасть ниже границы, а количество миддлов подняться выше.

Ну так дайте мидлу работу джуниора. Он не может с ней справиться? Странно. Или вы думаете, что обучение автоматически означает повышение зарплаты? Так нет.

Если не хватает сеньеров — их можно нанять.

Это если они на рынке есть. А то можно два года искать — и не найти.

При чем «больше заказов» с ростом разработчика Вы фиг возьмете, т.к. у Вас будет 20 начальников (сеньеров)

Вы почему-то считаете, что рост квалификации означает руководительские функции. Нет, это не так.
вы думаете, что обучение автоматически означает повышение зарплаты? Так нет.
Обучение — нет. Переход в статус миддла — да. Ибо во-первых мы же говорим о хорошем работодателе, а во-вторых иначе он уйдет.

Это если они на рынке есть. А то можно два года искать — и не найти.
А если их на рынке нет, то уйдет свой, только что выращенный, ибо конкуренция. И потеряете сразу двоих — и миддла (из-за обучения его до сеньера) и сеньера (из-за конкурентов) :)

Вы почему-то считаете, что рост квалификации означает руководительские функции.
Нет, это не так.
Обучение — нет. Переход в статус миддла — да.

Ну так переход в статус должен еще случиться.

во-вторых иначе он уйдет.

А он у вас в любом случае уйдет, если вас послушать.

А если их на рынке нет, то уйдет свой, только что выращенный, ибо конкуренция.

Так предложите условия лучше, в чем проблема?

Нет, это не так.

Тогда откуда «20 начальников (сеньеров)»?
Да и лояльность выращенного сеньера не просто не гарантирована, а напротив — практически гарантирована нелояльность. Потому что умный и любознательный разработчик не захочет застрять до пенсии в одной компании.

Я не могу сказать за всех, но лично я лоялен компании, которая хорошо ко мне относится. Предоставить мне возможность развиваться — это хорошее отношение; я не вижу, почему я должен относиться к такой компании хуже, чем к той, которая (а) не дает мне возможностей для адекватного развития и (б) считает, что единственный способ роста — это покинуть ее.
Я не могу сказать за всех, но лично я лоялен компании, которая хорошо ко мне относится.
И предложи Вам в соседнем офисе в 2 раза более хорошие условия, при том что у Вас ипотека и трое детей учатся — Вы все равно останетесь на старой работе?
99% людей в такой ситуации скажут «что-то компания ко мне плохо относится раз такие плохие условия тут, пойду-ка к соседям».
Но согласитесь, что это вообще никак не зависит от того, обучали меня в этой компании, или нет?
Именно, не зависит.
Так зачем компании тратить время деньги на Ваше обучение, если от этого не зависит Ваша лояльность, при том что шанс на Ваш уход повысится?
Типа компания за свои деньги должна себе же сделать хуже?
Э нет. Моя лояльность от этого зависит. Вы же написали «в два раза лучше условия», а не «в два раза больше денег». В мое понимание условий обучение тоже входит.
Достаточно странно не считать размер зарплаты одним из условий работы
Одним из, но не единственным. Соответственно, и зарплата, и обучение вносят свой вклад в мою лояльность.
тогда отошлем еще раз к предыдущему сообщению
habrahabr.ru/post/260201/#comment_8460695
Идеалистический взгляд хорош (я буду верен всегда), но при столкновении с реальностью быстро проходит (особенно когда нужда прижимает).
А я вам еще раз отвечу: в предыдущем сообщении написано «в два раза лучше условия». А если вы намекаете, что мне там предложат в два раза больше денег, так я вам честно скажу: я в золотую антилопу не верю, так что должен быть подвох. И состоит он в том, что либо я работаю на нынешнем месте сильно ниже рынка (а зачем?), либо на новом месте предлагают сильно выше рынка (а как так вышло?).
Как говорилось в том анекдоте — вот Ваше величество Вы и начали торговаться:)
p.s.: зарплата обученного специалиста и необученного может отличаться в 2 раза легко, но если в Вашей фирме нет вакансии на сеньера, то Вы будучи уже обученным сеньером, так и будете сидеть на зарплате миддла.
Как говорилось в том анекдоте — вот Ваше величество Вы и начали торговаться:)

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

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

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

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

Компании не нужно тратить деньги на обучение, если текущий уровень сотрудников её устраивает, а найти нового взамен уволившегося не проблема.

Нацеленный на развитие человек всё равно найдёт способы обучаться, но вот выше шансы, что он уйдёт оттуда, где ему не помогают обучаться (а то и мешают, хотя бы постоянными овератаймами и корпоративами). И не факт, что обучение будет идти не во вред основным рабочим-процессам.
Можно никому ни за что не платить, так как " все жеж знает Гугль ", а завтра помимо программирования размышлять над вопросом, почему в соседней стране началась гражданская война.
habrahabr.ru/info/help/rules
Хабрахабр — не для политики. На сайте крайне не приветствуются дискуссии на политические темы в любом их проявлении.
Выучивать не надо, нужно хотя бы раз прочитать, чтобы потом знать, куда копать
А апгрейд тогда в чем? (субж: апгрей до миддла).
То что кто-то прочитает книжку про апгрейд ноутбуков и будет знать куда копать — не сделает его ноутбук быстрее само по себе.
Прочитать недостаточно.
если брать сильный фреймворк то почему не Zend ?, всегда говорили что порог вхождения у него выше…
Похоже, Zend менее популярный
www.sitepoint.com/best-php-framework-2015-sitepoint-survey-results

и меньше community (сложнее будет найти ответы на вопросы)
36 694 — stackoverflow.com/questions/tagged/codeigniter
30 617 — stackoverflow.com/questions/tagged/symfony2
23 273 — stackoverflow.com/questions/tagged/cakephp
22 039 — stackoverflow.com/questions/tagged/laravel
18 740 — stackoverflow.com/questions/tagged/zend-framework
13 137 — stackoverflow.com/questions/tagged/yii
2 090 — stackoverflow.com/questions/tagged/kohana
930 — stackoverflow.com/questions/tagged/phalcon

Ну и не нравится он мне, поэтому и другим не советую :)
у Европы зенд пользуется очень большой популярностью в частности в Польше
Личный опыт с zf и symfony показал что порог вхождения в zend намного ниже, только нужно писать код на основе интерфейса, и лучше без замыканий в конфигурации. А в целом zend очень прост и приятен в использовании.
> nginx+PHP5-FPM — установка, Nginx изнутри, Тюнинг nginx
> Vagrant — документация, в PhpStorm
> Twitter Bootstrap — сайт

Вы уж определитесь кто именно вам нужен: php-программист, сисадмин или верстальщик. И при этом ни слова про базы данных, проектирование и оптимизация которых гораздо важнее чем вот это.
Twitter Bootstrap (или аналоги) как раз чтобы не изучать вёрстку, но при этом получить прилично выглядищий фронт без траты кучи времени на стилизацию.
Тсс… базы данных оставьте разработчикам бд )
Очень немногие проекты могут позволить себе отдельного разработчика баз данных.
Отдельный разработчик нужен только для очень серьезных проектов. Для типичных проектов нужен человек который просто хорошо разбирается в базах данных.
Т.е. просто понатыкать нужных компонентов не задумываясь почему всё именно так? Возможно.
Всё имеет свою цену. Делая выбор в пользу одного направления, жертвуешь всеми остальными. Чтобы задумываться, как всё устроено на всех уровнях абстракций всех направлений, надо для начала найти комнату вне пространства и времени. «Понатыкать нужных компонентов» может быть хорошим компромиссным решением в зависимости от ситуации.
Я советую прочитать 5 статей по nginx. Этого недостаточно, чтобы стать сисадмином, но достаточно, чтобы перестать отвечать на вопросы о том как оно работает «Не знаю, мне так настроили».

Просмотрев 5 страниц сайта getbootstrap.com, тоже верстальщиком не станешь, но сможешь сделать админку или первый вариант вёрстки приложения, не тратя лишнего времени и не требуя, чтобы верстальщики первые закончили свою работу.

Кстати, в книжке PHP+MySQL есть 50 страниц о базах данных, в книжке о Symfony — куча идей о проектировании приложения.
Вся проблема в том что там слишком много настроек и многие из них совсем не очевидны (вот тюнинг например зачем?). Да и ведь все равно никто и никогда не даст ковыряться в его настройках (как и в настройках бд) — поэтому и сомнительно это всё (могут конечно встреться задачи когда что-то не работает именно из-за особенностей настроек окружения, но это весьма маловероятно и обычно гуглится за 5-10 минут). ИМХО, лучше вместо этого почитать про php.ini (там есть интересные настройки), отладку (где оно кстати?), оптимизацию запросов, регулярные выражения (http://www.books.ru/books/regulyarnye-vyrazheniya-3-e-izdanie-592346/) и уязвимости (без которых вообще никак).
Моё мнение — каждый разработчик должен уметь самостоятельно настроить себе рабочее окружение. Сюда входит и установка любимой рабочей ОС на пустое железо (под рабочей ОС подразумевается какой-нибудь linux), так и установка и настройка всего требуемого софта: IDE, СУБД, интерпретаторы, веб-сервер и всё-всё-всё. А ещё каждый разработчик должен понимать базовые вещи, типа как работает Интернет (IP-адресация, DNS и т.п.). Джуниору плавать и чего-то не знать простительно, мидлу — уже нет.
Всего знать невозможно. Вот например postfix, необходимый для отправки почты, я так и не осилил — ну, извините, у меня есть куча других гораздо более интересных дел, которыми можно заняться вместо чтения 500 страничного талмуда по его настройке и десятка-другого связанных со всем этим RFC.
Для того, чтобы postfix работал на отправку почты с веб-приложения достаточно 20 строк конфига. Их нужно или знать, или знать где найти.
Никто не требует знать досконально все технологии. Нужно понимать как они работают и понимать какие-то базовые вещи.

Мидл от джуниора отличается не только опытом работы, но и развитым кругозором в разработке, а также (и это основное ИМХО) — умением полностью самостоятельно решать проблемы при решении задач
> Для того, чтобы postfix работал на отправку почты с веб-приложения достаточно 20 строк конфига. Их нужно или знать, или знать где найти.

К сожалению, я не могу ограничиться тупой копипастой 20 строк из гугла — привык разбираться :(
К сожалению, я не могу ограничиться тупой копипастой 20 строк из гугла — привык разбираться :(
Все равно приходится где-то проводить грань и Вы ее тоже проводите.
Когда Вы пишите на php ksort — Вы вряд ли разбираетесь с точностью до машинных кодов что именно тут происходит.
Да, изучите Вы что значат строки конфига по докам. Но без знакомства с сырцами постфикса опять же — получается не будете знать почему и как он эти строки реализует и все вытекающие из этого моменты.
> Когда Вы пишите на php ksort

Нет конечно, но вот сами алгоритмы сортировки гораздо нужнее в работе программиста чем настройка чего-то заковыристого и входящего в обязанности сисадмина :)
Нет конечно, но вот сами алгоритмы сортировки гораздо нужнее в работе программиста чем настройка чего-то заковыристого и входящего в обязанности сисадмина :)
Так поэтому и не надо настраивать что-то заковыристое, надо просто скопипастить 20 строк:)
НЛО прилетело и опубликовало эту надпись здесь
Странно, что ничего нет про базы данных (например, MySQL и Mongo, как самые популярные, лично я бы взял PostgrSQL и CouchDB, но это вкусовщина) и хранилища ключ-значение (memcached), на уровне более высокм чем создать табличку и сделать селект, но при этом есть PhpStorm и Vagrant. У разработчика уровня middle навыки профилирования и оптимизации запросов к хранилищам (в том числе путём кэширования в других хранилищах) должны быть обязательно, как и начальные навыки их (хранилищ) администрирования.
В первой книжке (PHP+MySQL) есть 50 страниц только о базах данных. В книжке по Symfony есть много о Doctrine (не поверите, многие не знают, что такое ORM и Active Record)

Но я писал на основе проведённых собеседований. MySQL с горем пополам почти все знают, а вот в других областях — пробелы.
Хотя такой вопрос многих ставит в тупик: «Если индексы такие хорошие, почему их сразу не встроят так, чтобы у всех таблиц были на все поля индексы?» :)
Я всех в тупик ставлю вопросом о том, что такое CSRF и с чем его готовить. (Спрашиваю нормально, так что не знающий термина но знающий атаку сможет ответить)
95% соискателей или вообще не интересуются безопасностью (велосипедостроители или любители жумлы, идущие на юниоров), или считают что «за нас уже всё сделано, и фреймворк решает все задачи безопасности, поэтому я и использую фреймворк.
Когда показываешь им, что в фреймворке защиту еще надо включить — удивляются.
Собственно я режу по тому как они реагируют. Если по моим подсказкам быстро понимают как лечиться, и в чем проблема, то ок, если нет, то большой жирный минус в анкету получают, который смыть сложно)

Второй вопрос на котором виснут 100% соискателей вне зависимости от уровня это моя просьба нарисовать блоксхему решения квадратного уравнения. Сеньоры обижаются почти все, мидлы через одного, и при этом когда после трех переспрашиваний серьезно ли я, они таки ее рисуют, то… в общем картина сразу показывает кто сеньор, а кто никогда им не станет несмотря на уровень знаний в три раза выше моего…
А почему именно квадратное уравнение? Почему бы не попросить нарисовать блок-схему «как копать картошку»? Я вот сейчас представил, каким был бы я, если бы не умел решать такое уравнение, и понял, что ничего бы не изменилось, разве что пару двоек в школе получил бы.

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

Опять таки, если 100% соискателей показывают одинаковые результаты теста, то к чему он?
Если с CSRF понятно, то что вы пытаетесь выяснить (найти) в соискателе, предлагая задачу с блоксхемой? Какие цели она преследует?
Kroid доступ к википедии не запрещен. Не помнишь что такое блок-схема, пиши на псевдокоде… не проблема.
vyacheslav_ka смысл в том, что часть людей сыпятся на том, чтобы найти простую инфу о простом алгоритме, половина сыпится на том, что рисуют блоксхему из пары блоков, без учета тривиальных случаев… В общем блоксхема в большинстве случаев не учитывает все возможные ситуации. Мысленное покрытие тестами равно нулю.
В принципе это нормально, если человек после первого намека исправит всё, то ок, если же начнет оправдываться и т.п., сопротивляться мол «вы серьезно такое легкое задаете», то тут уже разбираем псих-совместимость…
На самом деле это комплексный тест :)
Просто интерсно: прямо на собеседовании вы позволяете загуглить любой вопрос? Или же только википедией воспользоваться?
Конечно любой.
Нельзя знать всё что тебе нужно (по крайней мере программирование это та сфера в которой это так), но можно уметь быстро найти и понять то, что тебе нужно. Есть вещи которые человек должен знать. Есть вещи которые человек должен быстро понять если не знает. Но в основном важно понимание а не знание.
Ну сделает человек поиск в гугле по картинкам запрос «блоксхема решения квадратного уравнения» (без кавычек).
Ну и что это ему даст? Ну вот представим, что я при этом не буду за ним следить.
Возьмет первую блок-схему.
Даже вспомнит что-то такое из математики и не будет задаваться вопросом что такое «ДКН»…
Дальше что?
Он получит на этом этапе пару жирных плюсов за то, что нашел быстрое решение, и небольшой минус за то, что оно неправильное.
Я начну мягко его подводить к тому, что он ошибся (двадцать лет назад я тоже так же само ошибся, у всех бывает).
Сначала мягко намекну. Например попрошу «защитить» его решение, как диплом… Пусть объяснит зачем нужны каждый из блоков. Что бы было, если бы его не было… Не понятно? Ну вот к примеру, если бы не было блока начало, то программа бы не началась, если бы не было блока ввода параметров, то мы бы не знали что вычислять… Расскажите дальше…
Если после тонкого намека он не поймет, что кое-что забыл, то будет намек потолще:
«Если я вам сейчас скажу, что в этой блок-схеме есть большая, жирная ошибка, то в чем она по вашему будет? Попробуйте найти ошибку». Если и тут он не поймет, то он получит еще один минусик (после тонкого мог не понять от нервов или просто я слишком тонко намекнул, аналогия неочевидна...).
Дальше попрошу «максимально покрыть тестами». Для простоты можно просто привести некоторое количество наборов исходных данных которые по вашему мнению достаточно хорошо проверят правильность работы нашего алгоритма. Если и тут он не найдет ошибку, то простите, но сеньора ему не видать. Объясню ошибку. Посмотрю на реакцию и всё такое…
Если человек быстро нашел ошибку, или просто выглядит очень перспективно, то дам вопрос со звездочкой. Попрошу найти умолчание, которое мы в этом решении предположили, потому что когда мы в школе учили квадратные уравнения некоторых понятий мы не знали, да и сейчас можем знать смутно. Но подсказка в нашей искомой блок-схеме (Найденной в гугле) есть. Найдет — отлично. Не найдет, то подскажу. Предложу теперь, когда он уже всё понял, и достал жирафа из холодильника, попробовать таки нарисовать идеальную блок-схему… Я кстати пересмотрел два десятка картинок из выдачи гугла, но идеальной там не нашел.

Отдельным блоком идет проверка человека на психологическую совместимость работы со мной. Даю 5 против 1, что минимум 8 из тех девятерых что минусанули мой коммент банально считали вопрос слишком простым, или слишком сложным, не разбираясь, не стали бы выполнять пусть и «слишком простое задание», или искать в гугле математику, если оно показалось слишком сложным. Это вопрос психологии, не навыков или знаний. Люблю когда подчиненные делают мне обоснованные замечания или задают уточняющие вопросы. Но вот с такими вот людьми мне было бы сложно сработаться, и при отсутствии у них других очень жирных плюсов, я бы их зарезал… Ничего личного, может пиво было бы и хорошо с ними пить, или даже какие-то заказы на аутсорсе заказывать, но не работать в команде. :)
Господа минусующие (особенно туда, о чем не говорят), а можно аргументацию?
Ну хоть какую-то?
Я люблю независимое мнение, и поэтому довольно часто бываю не прав… Давным давно я ругался на тех, кто убрал из моих любимых языков GOTO. Потом я де матерился, когда услышал что его собираются вернуть в пхп… Я считал зажравшимися идиотами тех кто хочет цветной монитор, а мышку считал пижонством, ведь есть стрелки курсора. Но чтобы признать свою неправоту мне нужны аргументы. Если их нет, то как-то появляется легкое неуважение к оппоненту. Совсем-совсем легкое… :)
Не минусовал, но могу поспорить, что все дело в квадратном уравнении. Такие вопросы всех достали еще с тех пор, когда популярно было спрашивать «почему канализационные люки круглые».
Я не знаю почему они круглые, я не специалист в люках. Но готов предположить, что это как-то связано или с технологическими особенностями самих шахт, на которых они стоят (что далеко не факт), или с тем, что так нагрузка распределяется более менее равномерно при любом угле с которого на него ложится нагрузка… и кстати не совсем круглые, там есть бороздка и лапки (как правило).
Дорогой собеседующий, подскажите, а почему собственно? Мне уже любопытно стало)…

Искренне не понимаю чем такой вопрос может раздражать? Мало ли какая цель у интервьюера? Я пока первые сто человек сам не отсобеседовал (на разные должности), да первый десяток сотрудников не уволил (из тех кто был «хороший малый», и личных претензий не было), так я и не брался оценивать того кто меня собеседует… Что я делаю не так?
Я тоже не специалист в люках, но самое логичное объяснение — у круга одинаковый диаметр, как бы ты его не мерил, поэтому его нельзя уронить в канализацию — не пролезет.

Забавно бывает, когда на такой вопрос показываешь картинку вроде этой:
Картинка
image


Я еще раз обдумал это, после того, как вы подробней описали про вопрос, и вот что надумал. Если собеседуем джуниора — что у него можно спросить, он же ничего не знает и ничего не умеет, на то и называется джуниором. Тут да, остаются только вопросы на логическое мышление, на внимательность, на способность гуглить. Но если нам посчастливилось найти человека с опытом, можно сразу по существу спрашивать. Посмотреть код на гитхабе, вместе набросать структуру таблиц в бд для абстрактного проекта, сделать необычную валидацию в модели, написать тест для этой валидации.

С другой стороны, тут я теоретик — никогда никого не собеседовал и не горю желанием начать.

p.s. А ваши на собеседовании правда гуглят прямо так — «блок-схема квадратного уравнения»? Наверное, я сейчас тут кучу народу обижу, но не могу удержаться.
php guy картинка
image
Вы правы в том, что обычно хватает и других вопросов.
И в реальности я этот вопрос задаю редко.
Когда есть какие-то сомнения, когда ограниченный контакт (друг просил собеседовать ему ПМ-ов, и в один раз когда у меня не было времени ехать к нему в офис он попросил вопросы которые он может задать кандидату в скайпе. Да, там были квадратные уравнения).
Не соглашусь с вами в том, что тесты на логику сеньорам не нужны. Иногда такие перлы выплывают… Даже у очень опытных разработчиков. Я по опыту понял, что идея «у опытных азы не проверяем» плоха. Другое дело, что можно азы проверить очень быстро, буквально за две-три фразы.

На счет того как гуглят. Нет, так не гуглят. Ни одного такого не было. Видно по инерции считают, что я восприму это как читерство.
С вопросами на логику нужно очень осторожно. Я например очень плохо решаю логические загадки типа люков или выключенных лампочек в другой комнате, но очень хорошо поинмаю программы или вообще структуры данных. Я не понимаю паттернов если их объясняют в словах, но на лету схватываю если прочитать код.
А логика и структурное восприятие — вообще немного разные вещи, на самом деле.
Ну именно в логике мне интересен больше ход мыслей чем результат.
Да и то лучше ближе к реальности. Многие подвисают когда им дают волка козу и капусту…
Ну возможно это всё-таки вкусовщина.
Сильно зависит от задач.
IDE должна быть обязательно в плане на учебу.
Работа с базами да, важна. Но направление и глубина сильно зависит от тех проектов с которыми надо работать и от изначального уровня знаний человека. Если наш юниор в свое время успел слепить с пяток баз в Аксессе, и задачи у него не сильно хайлоад, то можно не сильно глубоко изучать возложив всё на ORM.
И да, я бы выкинул 80% предметов связанных с админством.
Но опять таки, в некоторых командах это ложится на мидла.
Я бы сделал больше упор на Гит, который тут по верхам очень…
Но повторюсь — это во многом вкусовщина.
Что ты не делай, а за три месяца у тебя будет уровень такой, что тебя до мидла ПМ-у еще от месяца до трех нужно будет дотягивать, ибо работа в команде, специфика конкретной команды…
Вот так прочитаешь все это, найдешь хорошую вакансию,
а там используется Yii (потому что не у всех IQ больше 120),
PostgreSQL (по некоторым причинам),
Smarty (или вообще без отдельного шаблонизатора),
nginx-ом управляют сениоры (которые давно там работают и хорошо знают проект).

Вообще, мне кажется, в статье описан middle, который ближе к senior, почему автор и отсеял 90% кандидатов. Вот тут есть хорошее описание.
Yii

Мне тоже Yii нравится — первый был так себе, а второй — очень даже. Среди собеседуемых (более 100 человек за последний месяц, считаем статистически значимым) — 50% не пользовались активно фреймворками (Joomla / Magento / Drupal /… — не считаются), 45% — Yii / CodeIgniter / Laravel, 5% — Symfony.
На Yii / CodeIgniter можно сделать приложение, не зная почти ничего и не используя сторонних библиотек. Это прекрасно, но очень расслабляет и не заставляет учить новое.

PostrgreSQL

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

Smarty

К счастью, Twig уже немного популярнее и, думаю, тенденция продолжится.
3 733 — stackoverflow.com/questions/tagged/twig
3 108 — stackoverflow.com/questions/tagged/smarty
Но шаблонизатор — это не так критично, поэтому он в разделе «Статьи», а не «Книжки»

nginx-ом управляют сениоры

Я вообще за автоматический деплой — нечего людям лезть в продакшн-сервера.
Но основы nginx знать нужно.
Тут кстати большая дилема с фреймворком наблюдается.
Yii1 идеален для изучения начинающим, хоть и чуть кривоват. Yii2 свежее, очень приятен, современен, имеет много решенных проблем, и хоть первый и долго будет поддерживаться, но начинать новые проекты с первым, да еще и учить его как основу — плохой тон. При этом у второго еще недостаточно развитая экосистема. Если ты опытен в других фреймворках или хорошо знаешь первый, то это не проблема. Но для нуба… В общем я большой сторонник Yii, я оставил ее себе как основную технологию, потому что ее знают многие, при этом уступает конкурентам она мало в чем. Но вот как первый фреймворк… не уверен. Своих нубов я пытаюсь садить на Yii2, но сомнение у меня всё еще есть…
Я бы многое отдал за четкий список того, что должен уметь джуниор/мидл/сеньер. Но мне кажется таких критериев просто не существует. Ибо на разных проектах бывают разные задачи. С некоторыми пунктами я безусловно согласен.

1) Список книг — безусловно зачет, особенно совершенный код, это маст хэв для любого разработчика.

2) С фреймворком не согласен. Да я понимаю, почему вы выбрали симфони, но не знание его не делает разработчика плохим. Так же те кто писал например на ларваеле смогут без проблем сделать блог на симфони, но изучить все его тонкости за это время они врядли смогут.

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

Но в целом не плохая статья. Приятно ощутить себя опытным разработчиком. Хотелось бы узнать, какая ЗП у вас для такого разработчика и какой список требований вы предъявляете для сеньера?
Ну вот со «Свитером» не соглашусь. Знание Бутстрапа как раз освобождает от верстки…
В реальной жизни мидл должен понимать основы работы на стороне клиента. ЖаваСкрипт, классы, ИД… Всё это не обязательно знать глубоко, но элементарно надо знать. И хоть понимать что ты отдашь фронтдевелоперу, а что оставят тебе ибо нефиг…
А Бутстрап это фактически и есть легкое манипулирование классами, да базовый HTML.
Я не говорю, что знать бутстрап не нужно или лишне, это даже не тяжело. Но если в команде есть верстальщик, знать просто html без css вполне достаточно. Можно оформлать вывод в обычные списки, таблицы и т.д. Верстальщику в принципе все равно что переверстывать.
Мидл который не знает css? Ну ок, я сам такой, что всегда все вопросы гуглю. Но бутстрап, Карл, бутстрап?
Задача сделать CRUD контроллер для админки. Требований к оформлению нет никаких. Верстаем ему view абы как и бежим к верстальщику чтобы он нам «хоть какой-то бутстрап» натянул? Не попахивает ли это юниором?
Мидл который занимается бэкэндом не? Или мидл который делает rest api? Почему вы все пытаетесть примерить на себя? Человек может проработать 5 лет в одной организации, быть богом программирования, писать отличный код, разрабатывать невероятные алгоритмы и при этом в глаза не видеть html, вообще.
может и не видеть.
проблем нет никаких.
Но с таким успехом можно выкинуть 100% материала описанного в статье.
А в среднем по больнице хтмл видеть приходится.
Не 100%. «Совершенный код» нужно читать каждому, разираться с mysql многим, ООП и паттерны вообще к языку не привязанны. Даже twig уже имеет порты на другие языки. Статья полезная просто я не со всем в ней согласен. Я не понимаю почему вас так возмущает мое видение на потребность в бустрапе.
Почему возмущает? Я сам долго работал по такому принципу как вы говорите — верстал тупой хтмл, чтобы хоть структуру было видно, и я сам мог проверить работоспособность всего остального, а верстальщик уже делал всё остальное. Но потом появился бутстрап, и как-то сразу пропал смысл делать голый хтмл.
Ну и вы ощутили от этого какой то особый профит? Я понимаю, что добавлять бутстраповские классы не тяжело, а внешний вид радует глаз, но это не влияет на уровень скиловааности программиста, если он не верстальщик.

А проверять результат можно и нужно и тестами.
Ну так если не тяжело, то почему бы и не добавить? :)
вопрос скорости решения задачи. Плюс на бутстрапе часто можно уже работать, потом допиливая. На чистом обычно не пойдет… Но в любом случае это мелочь.
Я оспаривал его только потому, что вопрос был поставлен не в ключе знания полезных инструментов, а именно в ключе милд девелопера на php. А в этом контексте, знание или не знание бустрапа роли не играет)
Ну я брал мидла без знания бутстрапа. С формулировкой «выучишь за неделю».
Верстальщик в команде был.
Скажем так я спорил потому что считаю что бутстрап много важнее Vagrant-а и т.п.
При прочих равных во многих случаях играет.
Программирование, даже на php, это не только круд и админки. Возможно мне легче такое понять, потому что работаю в организации где всем плевать на интерфесы, важны алгоритмы обработки данных.
конечно не только)
но и это как правило тоже. И за такой мелочью бегать к верстальщику, согласовывать этот вопрос с ПМ… Объяснять что ты хочешь чтобы сделали… Прочитать буотстрап, и написать самому пяток примеров это один вечер. Верстать 3 минуты, организовать чтобы верстал кто-то другой, и проконтролировать — суммарно с полчаса выйдет.
Обычно если есть верстальщик, объяснять, что версать не нужно, так как верстка делается паралельно, а то и даже раньше чем код. Тут остается только наполнить данными.

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

Я вам бесплатно расскажу — четкого списка вы нигде и никогда не найдете (его и не может быть), всегда будут какие-либо вариации на тему. А вот следующую фразу я считаю гениальной :) «Вы можете считать себя Senior, когда вы сможете вести полный цикл разработки в одиночку.»

На разных проектах, в разных компаниях цикла разработки и инструментарий может быть совершенно разным, согласитесь? Именно поэтому, если вы сейчас Senior в своей компании, это не означает, что вы сможете перейти в другую компанию и остаться Senior.
Встречал вакансию под названием «Senior Wordpress Developer».
И вы знаете — в этом названии таки да, была большая доля логики.
З/п там была достаточно интересной на тот момент, так что я даже потратил неделю времени чтобы изучить ВП))
Потом правда у них оказалась более интересная вакансия, но это уже другая история.
Теперь давайте уточним, что считается полным циклом разработки в вашем понимании (или понимании того, от кого вы эту фразу услышали). Сюда входит сбор и анализ требований? Проектирование? Тестирование?
Как я это понимаю (в рамках двух последних мест работы):
  • предварительный этап: общение с заказчиком и сбор требований, анализ требований с последующим дизайном решения (выбор технологий в том числе), превращение всего этого добра в ТЗ, оценка задач и построение плана работ
  • разработка: написание и хранение (version control) кода, подготовка сред (dev, qa, live) и серверов (вы можете сами настраивать сервера и сервисы, но можете и привлекать внешние ресурсы — главное, чтобы вы понимали «базу» и знали точно что вам нужно, могли контролировать человеческие ресурсы вне вашей команды), code review, refactoring
  • поддержка проекта: баг-фиксы, дальнейшее развитие/расшиение приложения


Естественно, это лишь общая картинка. Конкретный стек технологий и этапов цикла разработки зависит от конкретной компании.

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

Возникает вопрос: а зачем тогда вообще нужны аналитики? Архитекторы? РП? Администраторы?
Затем же, зачем нужно разделение труда. Идея в том, что человек на вершине, который отвечает за итоговый результат, должен уметь сделать всё в одиночку, а не в том, что нужно делать всё самому.
А вы считаете, что Senior Developer — это «человек на вершине, который отвечает за итоговый результат»?

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

Смотрите, у нас есть профессия и шкала с 4 отметками, определяющая некое количество знаний и умений по профессии: посторонний, начинающий, довольно умелый, на вершине умений. Можно сидеть и изобретать подробные метрики для оценки принадлежности человека к какому-либо уровню, если вам платят за придумывание метрик. Если же нужно определить на глазок, критерий «способен сделать самостоятельно любую задачу в своей области == сеньер» вполне достаточен.

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

Фундаментальный вопрос состоит в том, что считать «свой областью». Я, в принципе, тоже считаю, что senior developer — это такой разработчик, который способен самостоятельно сделать любую задачу в своей области, я просто не считаю, что (а) тестирование (б) сборка требований (ц) управление проектом (д) настройка и поддержка продуктивной среды являются его областями деятельности.
>> Сюда входит сбор и анализ требований? Проектирование? Тестирование?

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

Это противоречит изначальному «в одиночку».
На все ваши текущие вопросы я уже ответил в двух своих комментариях выше, новых вопросов не увидел.

Вы начинаете придираться к формулировкам (троллить?). Если вы приципиально не согласны с моим мнением, то задачи переубедить вас в чем-либо у меня и не было и нет, поэтому просто примите еще одну точку зрения как пищу для размышлений.
>> Возникает вопрос: а зачем тогда вообще нужны аналитики? Архитекторы? РП? Администраторы?

А как ваш вопрос соотносится с тем, что я написал? Цитирую себя же: "...Senior должен знать что происходит на этих этапах и либо сам это делать (нужны знания), либо привлекать внешние ресурсы, которые он будет способен контролировать (а я для этого тоже нужны хотя бы базовые знания)...".

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

Итого: в теории у Senior'а должно хватить знаний, чтобы суметь все сделать в одиночку (естественно, качество результата работы целой команды и одного единственного человека может отличаться в разы). Возможность делегирования это всего лишь возможность сделать работу быстрее и качественнее, Senior все равное должен понимать а) что он заказал, б) для чего, и в) как оценить результат — то есть в упрощенном виде он и сам должен уметь сделать что-то подобное.
Как проконтролировать работу человека, который разбирается в вопросе существенно лучше тебя?
Для этого нужно лишь знать основы (базовые знания в некоторой сфере) и понимать метрики для контроля правильности/качества результата. Если следовать вашей логике, то все руководители должны быть умнее своих подчиненных, а это далеко не является истиной также, как и обратная ситуация — не всегда подчиненные умнее руководителя.

Давайте теперь узнаем ваше определение разработчика уровня Senior. Хочу понять разницу во взглядах и причину «придирок» :)
В моем понимании разработчик уровня Senior — это разработчик, который способен самостоятельно решить поставленную перед ним задачу по разработке системы средней сложности (естественно, с необходимым и достаточным уровнем качества).
У разных руководителей разные метрики правильности/качества. Я не понимаю, каким образом вы предлагаете senior developer контролировать работу, скажем, бизнес-аналитика. Впрочем, еще мне интереснее, чем senior developer, делегировавший всю работу остальным, отличается от руководителя проекта.
Давайте разберем на примере: где эти самые бизнес-аналитики или руководители проектов в маленьких компаниях/командах? Кто выполняет их работу? Анализирует требования и пишет ТЗ, разбивает на задачи и оценивает их, тестирует результат и настраивает сервера — кто все это делает в команде из 3 человек? Директор? Дизайнер? Разработчик?
Во-первых, из кого состоит ваша «команда из трех человек»?
Во-вторых, а всегда ли в команде из трех человек есть написанные требования и ТЗ?

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

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

Баш, вагрант, твиттер тоже не обязательно. Хоть я сам и знаю их

Ага ) Надо хотя бы понимать основы. Я бы ещё добавил недооценённый программистами Excel / LibreCalc, который как и bash помогает решать одноразовые задачи, но и так получился холиварный список.
А можно тогда спросить, что такого в этой книге, так как я ее не читал.
Достаточный, чтобы посмотреть wiki :-P,
функ-ци-о-на́л
комп. жарг., собир. то же, что функциональность; набор функций, возможностей, предоставляемых компьютерной программой, библиотекой функций и т. п.

Но, раз многие несогласны, поменял на «минимум фич».
Symfony 2 book — скачать на английском, частичный перевод на русский

Я его забросил после выхода 2.1, когда половину книги пришлось переводить заново… Как оказалось, поддерживать перевод в одиночку нереально, а никто больше в официальный русский репо не коммитил =(

К чему я это — там очень устаревшая документация. Не уверен что на нее стоит ссылаться.

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

Возможно, неправильно сформулировал. Смысл предложения — вы все (на Хабре средний IQ явно выше 120) достаточно умные, чтобы понять и более сложные штуки, поэтому не нойте, а разбирайтесь. Для обучения лучше выбрать хоть и сложную технологию, но очень гибкую (сложность — не самоцель), с хорошим учебником и сообществом.

Для решения потом практических задач часто экономически нецелесообразно использовать Symfony.
Мы у себя и не используем — берём только отдельные компоненты и по факту конструируем свой фреймворк.
Эх… Давно мечтаю о книге (или написать ее самому?), в которой будет кратко описаны современные инструменты web-разработчика, их сравнение, особенности, но без упора на конкретное решение (не книга о Symfony, а книга о web-фреймворках, не книга о Smarty, а книга о back-end шаблонизаторах, не книга о Redis, а книга о NoSQL хранилищах).

Многие считаю, что к моменту издания этой книги, технологии сильно устареют. Мне кажется, что если книга не будет делать упор на конкретное решение, то она станет культовой и не устареет даже через десяток лет.
> Symfony 2 book
Для человека не имеющего хорошего опыта работы с фреймворками, большая часть текста или будет не понята, или без практики выветрится из головы через неделю-другую. Лучше уж взять систему попроще, но не просто почитать, а сразу применить в каком-то простеньком проекте.
Тоже касается ООП, паттернов и другого, можно зазубрить определения, но в работе это слабо поможет и на собеседовании выявляется легко, например по собственному опыту люди изучавшие ООП, но мало его использующие не могут описать всех отличий интерфейсов и абстрактных классов, ограничиваясь лишь общими словами.
Выучить на память TOP100-300 функций PHP (1 неделя)

Это по-моему самое бесполезное занятие. Как на зачете — выучил чтобы забыть через пол часа после сдачи. С учетом того что переходный уровень Junior -> Middle уже предполагает уверенное использование документации, достаточно просто пробежаться глазами по списку стандартных функций/классов с кратким описанием, чтобы в дальнейшем не городить велосипеды.
Особенно при наличии сторма в списке.
Если вы программировали много и разное, то вам уже не нужно. Но, опять же, писал по результатам собеседований. Как минимум половина не может без мануала вспомнить и 10 функций для работы с массивами (а их — 79), а иногда и 10 функций для работы со строками (которых 98).

Можно выучить и забыть, это нормально. Но хотя бы помнить — «кажется, была такая функция, надо посмотреть»
В.НЕТ тысячи классов и десятки если не сотни тысяч методов и свойсв, это невозможно запомнить. Человек должен знать что и где искать, а не как называется тот или иной метод. К тому же есть более полезные вещи которыми можно занять память.
НЛО прилетело и опубликовало эту надпись здесь
Конечно, лучше потратить несколько лет, но получить более глубокие знания.
Я надеюсь, что мои советы дадут хороший эффект за минимальное время.


НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Ну написал ты план и что?
Я раньше думал, что уровень программиста зависит совсем от других параметров, чем знание какого-то конкретного узкого инструмента и тех или иных подходов к структурному написанию кода. Даже уходя от того, что сам язык программирования — лишь инструмент для решения конкретной задачи, на мой скромный взгляд далеко не умение использовать набор готовых решений делает программиста продвинутым, и уж тем более не знание оболочек-редакторов.
Видел я одного, как это модно говорить, «миддла», который при помощи констукций zend фреймворка делал в цикле select к базе под 300 тысяч записей.
Месяц 2

nginx+PHP5-FPM — установка, Nginx изнутри, Тюнинг nginx


Угу, а потом такого понавыдумывают… За три месяца это всё освоить не выйдет.
Ах да, совсем забыл — а потом вам админ передаст «большой привет», когда вы своими запросами приложите базу, ведь одной «PHP и MySQL» будет недостаточно.
Статья хорошая, но после
Предвидя холивар «почему Symfony»: если у вас IQ меньше 120 (без обид, многое заложено генетически, но вы точно хотите быть программистом?), то выберите Yii или Laravel — они проще в изучении.
дочитывать было крайне тяжело.

Идентичную мысль можно сформулировать без наездов.

Также количество вопросов на Stackoverflow говорит лишь о том, что та или иная технология сложна, может быть даже неоправданно. К популярности фреймворка это имеет косвенное отношение.
Наезда нет, я пытался донести мысль, что Symfony действительно сложный, будет немного кипеть голова, но тут вроде собрались умные люди и это вполне по силам. А пользы для образования от Symfony с её хорошим учебником и интересными подходами будет больше.
Интересно услышать аргументацию автора по поводу IQ 120 и симфони. По моему слишком толсто.
Windows Yii позволят легко решить задачи, а Linux Symfony заставляет людей напрягать мозги, но в итоге они лучше понимают как работает компьютер.

Утрированно, конечно, но всё же.
А вдруг автор прав и мы все избранные с IQ > 120?
средний уровень IQ насколько я знаю уже не 100 а 110, по крайней мере из тех кто их хоть проходил…
думаю медиана на хабре должна быть около 130, а мат.ожидание около 125. Так что вполне логично.
Только толсто. Вкусовщина это, и разные задачи бывают. Зачем сразу оскорблять?)
Это как 99% оскорбляющих 1С-ников, и считающих их недопрограммистами не знают реальной причины почему собственно основная транскрипция на русском :) Считать себя умным приятно…
Вы разгадали мой секрет :)

Я пытался обратиться ко всем (на Хабре if (IQ > 120) так же бессмысленно как if (true)), немного потешив самолюбие читателя и одновременно дать небольшой пинок, чтобы не ныли, что «это нам сложно», «это мы не поймём».

Если кого-то вдруг обидел, извините — неприятный побочный эффект.

Хотя было очевидно, что это значительно понизит карму (так и случилось).
К счастью, мне на карму наплевать, я рад что многие добавили статью в избранное и, возможно, хоть на несколько хороших программистов через пару лет станет больше.
В избранное добавляют не только хорошие статьи.
Я бы за другое придрался. Думаю в основном ее добавляют не те, кто собирается это проходить, а те кто уже давно прошел, и будет на основе этого делать свой список… совсем-совсем другой, или те кто хочет послушать обсуждение, и подправить себе список что спрашивать на собесах :)
Спасибо автору за изложение мыслей, для некоторых будет очень даже познавательно. Но самое главное в таких статьях — это комментарии к ним. В них, зачастую, информации в несколько раз больше, чем в самой статье. Спасибо авторам комментариев — нашел для себя несколько новых вещей.
Когда я учился в университете, преподаватели настоятельно рекомендовали нам еще до первой работы прочитать банду четырех, чистый код и я считаю это верным, поскольку до начала коммерческой разработки у молодого специалиста уже должно быть сформировано какое-то понятие о хорошем и плохом коде
И как, поняли хоть что-нибудь из “Банды четырёх” без опыта коммерческой разработки?
Да, понял, не все, но какие то базовые паттерны в лухе синглтона, фабрик, декораторов запомнились еще тогда
Другое дело, что в процессе простения я искал примеры реального кода на гитхабе с применением практики, но это уже кто как самообучается
А потом приходишь на первую работу, а там разработчики работают по принцыпу «Х*як, х*як и в продакшн». И идеальный мир рушится на глазах. Для меня всегда было загадкой, почему в 99% вакансий указано знание паттернов, при том, что 99% программистов этих компаний даже самых базовых принципов ООП не соблюдают.
Это я все про Веб, если что, как в других сферах не знаю, но в веб все очень печально с этим. И разговор не о веб-студиях…
Прописал минимальный план желающим сделать рывок и перейти на следующий уровень без отрыва от производства.

Я правильно понял, что это результат размышлений, а не практики подготовки специалистов?
Это то, чего не хватает многим из тех, кого я собеседовал (за последние 10 лет, наверное, уже больше сотни людей лично и ещё больше по телефону).
Причём меня всегда удивляло, как люди с 2-3 летним опытом программирования на PHP не знают некоторых элементарных вещей, хотя при необходимом желании будущий специалист может подготовить себя сам, а не ныть «меня не учили».
Либо у людей нет желания, либо они не знают в каком направлении разбираться. Если второе, то эта статья им может помочь.
Я как-то на продакшен сервере патч Бримана применил.
Было это лет 10-12 назад. Админ пошутил, думал что раз я достаточно опытный, то обязан знать такие вещи.
А я на автомате ввел, а уже когда всё произошло, понял что же я ввел… Я со своей стороны думал что он достаточно ответственный чтобы так шутить))) У всех бывают пробелы в знаниях кажущихся очевидными.
У людей нет желания. Меня и Hello World писать не учили, что теперь? Какую цель-то в итоге преследует данная статья? Вы думаете Вам в команде нужны люди, которые не в силах посмотреть, какие нынче течения в их собственной сфере и не понимают, что надо знать и уметь, если хочешь расти дальше? Вы же сами сказали, что речь идет не о полных неофитах.
Ну и еще с Вашими рекомендациями можно не согласиться во многих местах, но это уже выше в Комментах сделали.

Причём меня всегда удивляло, как люди с 2-3 летним опытом программирования на PHP не знают некоторых элементарных вещей

Ок, допустим я занимался 2-3 года разработкой сервера для многопользовательской онлайн игры и использовал кучу крутых технологий, при этом понятия не имею о MySQL. Элементарная, казалось бы вещь, я непригоден для работы с Вами и не достоин быть middle-разработчиком?

И еще раз повторюсь про ваши критерии высказав такую точку зрения: куда более важно не что знает человек, а как он знает. И под «как» я подразумеваю образ мышления. А в эпоху легкодоступной информации в google многие знания(самый яркий пример — bootstrap) вообще ненужны — понадобилось, зашел в доки, быстро пробежал, бац, бац — готово. Всегда поражало, когда меня спрашивали заню ли я jQuery — что там мне ЗНАТЬ-то нужно?
по мне так, авторы комментов — представители желающих дое@баться до столба и минусануть чужое старание…
Пффф… 15 минут прошло и я — «отхабренный». Привет тебе, «система» и админ! Ссыте дальше друг другу в уши о свободе слова!
Раз уж ты, админушка, с говном меня смешал, удали-ка май акк отсюда, пжл, или буду очень вонючим дерьмом кидаться в адрес тебя и твоих собратьев. Уточню: ваш говноресурс даже удалиться нормально не позволяет.
Коллеги, прошло далеко не 3 месяца… Сколько новых миддлов появилось? Так, ради интереса :)
минус комментарию поставил я, аргументирую (а то сегодня плодят посты "хабр не тот", ака все злые и минусуют). Статья не плохая, автор полезные ссылки указал. А вот этот комментарий уничижительный.
А насчёт новых миддлов, я к примеру не знаю свой уровень, работаю уже много лет по удаленке. Читал почти всё из указанного в топике и постоянно читаю-изучаю новое. Если не повышать свой уровень, можно очень быстро остаться не при делах в этой сфере, тем более с удаленной работой.
Хм, не думал что этот комментарий может быть воспринят с такой стороны. Вопрос сугубо ради интереса — сколько человек после прочтения данного поста задумались и прочитали что-либо из указанного списка или последовали рекомендациям.
Рад, что ошибся. А так бы я хотел, чтобы люди с которыми иногда приходится работать прочитали некоторые рекомендации из статьи. А совершенный код я бы в институте обязательной программой сделал )
Берите выше — некоторых хочется отправить прочитать в документации базовые вещи… А вы про совершенный код...
Не знает половину функционала языка? Молодец какой. Я 90% функций PHP не знаю)
А если серьезно, то я недавно колупал один класс с адской конструкцией из двух десятков ифов.
Но это как-то совсем не раздражало. Ну не знает человек про switch, ну бывает. Я конечно переписал, но просто потому что…
это было в методе на сотни три-пять строк. Если бы человек не знал про switch но знал и понимал DRY, SOLID, MVC (тут именно понимал, потому что задекларированно таки MVC), PSR-2 или другой стандарт, и прочие базовые вещи, то я бы этот блок скорее всего даже не прочитал. А если бы и прочитал, то трогать бы не стал. Отнаследовался бы, переопределил бы нужный мне метод на 20 строк, максимум два, и всё.
А, то есть метод в 300-500 строк вы считаете нормой? Интересненько....
Где вы такое увидели в моих словах?)
Собственно я потому и заметил вообще саму конструкцию что такую громадину осознать было не просто и я стал ее рефакторить на горсть методов до 20, максимум 25 строк. Чисто чтобы читать проще было. Ну и в процессе уже преобразовал матрешку в свитч.
Уравнял счет. Нормальный комментарий, вы придираетесь. Вдруг кто ответит. Мне вот тоже интересно стало. Особенно, сделал ли кто проект на Гитхабе.
Все нижесказанное чистое ИМХО, не является конечной инстанцией и руководством к действию.
На хабре уже неоднократно появлялись статьи, что нужно знать для Junior, Middle и тому подобное. По-моему личному мнению, это зло. Человек изучит материалы, предоставленные вами, и будет ошибочно считать свой уровень = Middle. Вы уж извините, но ваша подборка материалов больше годится для Junior'ов. Но опять же, зачем спускаться до уровней? Middle должен обладать не набором каких-то конкретных технологий, а отличным пониманием, что, где, как и зачем. Middle уже по первому взгляду должен прикинуть примерное решение:

  • «Так, ага, здесь у нас отсылка письма с линком восстановления пароля, сделаем через очередь задач, чтобы фронт не тормозил» => «Можно взять beanstalkd, в прошлом он хорошо себя показал. Однако, я понимаю как можно самому реализовать простейшую очередь задач! К примеру, использовать Redis (=> Redis? Я знаю что redis это in-memory хранилище, с поддержкой перзистентности. Зачем? Например кэширующего слоя перед бд, возможно, выноса части бд в in-memory, для разгрузки медленных запросов. Для кэша есть еще memcached...). Redis single-threaded, поэтому я избегу race-condition при выборке новых задач. Нет Redis'a? Ok, могу сделать очередь поверх обычной таблицы! Использую LOCK FOR UPDATE, или просто обойдусь UPDATE. Я знаю что UPDATE блокирует строку!.. А может просто, потоко-небезопасный код обернуть в мьютекс — PHP Redlock?!»
  • «Так, с очередью ясно! Что по поводу отправки_писем? Заинжектю-ка я MailerInterface в логику отправки письма, вместо использования моего класса Mailer, я же знаю про DI, и завтра нам может понадобится другой сервис для отправки писем. Стоп. Мы же хотели в будущем сделать и восстановление паролей по sms? Назову-ка я лучше интерфейс NotificationInterface, сейчас реализую его для e-mail, а в будущем для sms»
  • «Нотификацию мы умеем отправлять. Что по поводу самого восстановления? Наверное, нам нужен какой-то секретный токен, который мы отправляем на NotificationInterface::send($notification, $user), а позже верифицируем, и удостоверяемся, что пользователь владеет e-mail/телефоном»
  • «С этим ясно, а как хранить токены для восстановления паролей будем? Создадим таблицу confirmation_tokens. Стоп. Готов поклясться, что Я уже делал что-то подобное когда-то на другом проекте, и понял, что секретные токены весьма многообразны в использовании, и подходят так же для: сброса пароля, ссылки — автологина, мерджа аккаунтов! Заведу ка я таблицу secret_tokens, будут методы acquire/verify. Ограничу токены по времени жизни — чтобы исключить перебор. Пока заведу только один тип токенов — TYPE_CONFIRM_EMAIL»
  • «С логикой вроде все ясно. Хм! Мы используем платный сервис для отсылки sms, будет нехорошо, если url /send_confirmation может дергатся неограниченное кол-во раз, с разными номерами телефонов. Так один пользователь может отправить и 1000 смс на разные номера! Можно отдавать куки, можно сверять IP. В принципе, я знаю как это сделать! Но постойте, у нас в Laravel есть замечательный throttle middleware! Он как раз призван ограничивать кол-во обращений к url'у, с привязкой к клиенту»
  • «Постойте, так у нас тут поле ввода Email проверяется AJAX'ом на существование. Это же уязвимость налицо! Можно построить список email всех пользователей сайта! Добавим ограничение и на урл /check_email
  • «Так, в форме надо не забыть еще и про CSRF. Да, я знаю что это! Same-origin policy не запрещает отправку кросс-доменных POST запросов, злоумышленник влегкую может использовать нашу сессию для сабмита POST'ов со своего сайта! Проверку CSRF можно реализовать поверх сессий, хранить токен, который сверять потом с прешедшим токеном в скрытом поле POST запроса. Но у нас в Frameworkе же есть готовое решение, {{ csrf_field() }}»



Лечге просто преподносить пост, как скопление полезного материала к прочтению.
  • Книга по 1ой книге — «Колесниченко», морально устарела. Первую главу — «Выбираем FTP клиент и текстовый редактор». FTP клиент? 2017. Мало того, не рекоммендую книгу данного автора, основываясь на своем и чужом опыте. Как и вообще многие русскоязычные книги. Официальная документация PHP — отличная кладезь знаний.
  • Vagrant — Docker
  • Выучить на память TOP100-300 функций PHP (1 неделя) — бывали такие вопросы на собеседованиях. Не ответил. Не жалею что не устроился на вакансии. Есть IDE, к чему знать названия? Главное знать что они есть.
  • Twitter Bootstrap, Twig — это совсем лишнее. Что там изучать? 5 — 15 минут чтения документации. Можно вообще не писать об этом.
  • Совершенный код — бесспорный лидер в подобных топиках. К прочтению обязателен. Однако, дает ли одно прочтение книги способность писать идеальный код? Однозначно нет. Нельзя даже сказать, что навык писать Идеальный код когда-то приходит. Это тот идеал, к которой нужно стремиться, но не делать первопричиной и самоцелью, в ущерб бизнесу. Качество кода несомненно всегда должно расти, лучший способ для этого — практика.


Гораздо более хорошо знать более базовые вещи (как бы банально и знакомо это не звучало), например:
— Английский язык
— Агоритмы/структуры данных
— Устройство Linux-подобных ОС
— Протокол HTTP
— Модель OSI
— И т.д.
Поправка, только сейчас увидел, что статья 2015 года, docker тогда еще не так актуален был.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории