Elm хорошее подтверждение Вашему заблуждению. И еще можно посмотреть на github реализации различных, вполне практичных вещей на Haskell. У меня часто возникает чувство: «Черт, почему я еще не пишу на Haskell»
Потому что перед тем как писать, надо сначало продумать свои решения и их архитектуру. Придумать ЧТО и КАК ИМЕННО ты будешь писать. Инче, вместо принятия правильных, красивых и изящных решений Вы принимаете первые попавшиеся, необдуманные и невыстраданные.
В первой тоже всё было в порядке с мотивацией и все знали что и как надо делать. Проблема лишь в том, что там как в ОП-посте было правило «СНАЧАЛА РАЗРАБАТЫВАЕМ ТЕСТЫ, ТОЛЬКО ПОТОМ ПИШЕМ КОД». Только вместо тестов стнед-ап митинги и планинг покер. Многие компании, в которых довелось работать пишут тесты ради тестов и работают по Scrum\XP ради работы по Srum\XP, понимаете о чем я? Инструменты и методологии нужно использовать тогда, когда это действительно необходимо. Иначе получается, что мы прикатываем экскаватор ради того, чтобы бы выкопать ямку в 10 см.
И это повальная проблема в разработке ПО. Мы берем фреймворки для разработки простых вещей, используем ООП для написания чего-то, что с легкостью укладывается в процедурную парадигму и так далее.
:) не думаю. музыка — она в душе. а код — это текст и
А для меня музыка это звуки, а код в душе. Об этом можно спорить бесконечно. У TDD-подхода есть одна важная обратная сторона — очень часто на выходе получается говно, потому что разработчик пишет так, чтобы проходило придуманные тесты, не сосредотачиваясь на том, КАК оно их проходит. Короче, для применения TDD нужне немалый опыт разработки, иначе это просто модное слово в списке используемых методологий, которое к тому же мешает разработке качественного кода.
Сразу вспомнил одну компанию, в которой довелось работать. Там было 4 разработчика, включая лида, все сидели в одном кабинете. Но мы каждое утро и вечер проводили stand-up митинги, отжирая час рабочего времени и каждую пятницу играли в planning poker, который, кстати, никогда не соответствовал реальности, но затрачивали на него часа 3-4, а в особо запущеных случаях весь. А компания делала свои собственные, не очень большие сайты.
Это просто к примеру мешающего «модного слова» в списке используемых модных слов. Потом перешел в компанию, где, несмотря на то, что народу было больше, не страдали фигней, а писали код. На прошлом месте за 3 месяца так ничего и не доделали до конца, на новом с нуля за месяц онлайн игру, выдерживающую 10к юзеров онлайн.
А потом приходишь на первую работу, а там разработчики работают по принцыпу «Х*як, х*як и в продакшн». И идеальный мир рушится на глазах. Для меня всегда было загадкой, почему в 99% вакансий указано знание паттернов, при том, что 99% программистов этих компаний даже самых базовых принципов ООП не соблюдают.
Это я все про Веб, если что, как в других сферах не знаю, но в веб все очень печально с этим. И разговор не о веб-студиях…
У людей нет желания. Меня и Hello World писать не учили, что теперь? Какую цель-то в итоге преследует данная статья? Вы думаете Вам в команде нужны люди, которые не в силах посмотреть, какие нынче течения в их собственной сфере и не понимают, что надо знать и уметь, если хочешь расти дальше? Вы же сами сказали, что речь идет не о полных неофитах.
Ну и еще с Вашими рекомендациями можно не согласиться во многих местах, но это уже выше в Комментах сделали.
Причём меня всегда удивляло, как люди с 2-3 летним опытом программирования на PHP не знают некоторых элементарных вещей
Ок, допустим я занимался 2-3 года разработкой сервера для многопользовательской онлайн игры и использовал кучу крутых технологий, при этом понятия не имею о MySQL. Элементарная, казалось бы вещь, я непригоден для работы с Вами и не достоин быть middle-разработчиком?
И еще раз повторюсь про ваши критерии высказав такую точку зрения: куда более важно не что знает человек, а как он знает. И под «как» я подразумеваю образ мышления. А в эпоху легкодоступной информации в google многие знания(самый яркий пример — bootstrap) вообще ненужны — понадобилось, зашел в доки, быстро пробежал, бац, бац — готово. Всегда поражало, когда меня спрашивали заню ли я jQuery — что там мне ЗНАТЬ-то нужно?
Вот в точку прямо, примерно об этом я и говорю, это почему-то очень распространено у разработчиков на Yii. Мне кажется, дело в документации. Среди разработчиков на ZF2, по ощущениям такое встречается реже.
Я вас просто неправильно понял, подумал, что речь идет скорее о возможности(невозможности) использования современных инструментов вроде того же composer, при использовании Yii, затем и был сброшен бойлерплейт, как самый быстрый и понятный пример того, что все зависит от программиста. Если вести разговор в ключе «фреймворк — это инструмент, и он должен быть удобен. » — я полностью согласен. Трудно оценить то, насколько человек понимает роль фреймворка и возможности его использования по паре сообщений в комментариях, а практика показывает, что очень многие разработчики на PHP плохо понимают, что все находится в их собственных руках в бОльшей степени, нежели в руках фреймворка. В общем, мы по-разному расставили акценты, вот и все. Но спасибо за диалог ;)
Вы убеждаете меня в том, что грязная треснутая ржавая лопата, хотя и делающая свое дело, лучше новой титановой лопаты из современных легких материалов.
Вы меня совсем не читаете что ли? Я ни разу не убеждал вас, что Yii 1 лучше хоть чего-то. Я лишь говорил о том, что он не так плох, как вы думаете.
НО! В целом я согласен, что в эпоху Laravel, Yii 2, Symfony 2 выбор неоправдан для такого проекта.
мне не мешает использовать данные вещи ничего, но это не используется в самом yii.
С этим никто не спорит
Вы, как топикстартер соседней темы про yii2, путаете приложение на базе yii и сам yii.
Что, простите? Какой еще темы про Yii 2? С чего вы взяли, что я что-то путаю? Я прекрасно понимаю разницу и даже написал об этом выше.
Кодстайл — это мелочь, которая к функционалу никак не относится, но выглядит дико.
Если об этом говорить, то кодстайл в Yii2 тоже не лишен недостатков
Не надо меня переубеждать — я каждый день работаю над сайтом на yii1, пишу сайты для себя на yii2, и в курсе всего yii-шного бэкграунда.
Я Вас поздравляю, я не работаю каждый день с Yii1 и сайты для себя на Yii2 не пишу, но это не меняет абсолютно ничего, к чему вы это? Я знаю людей, которые работают с yii1 каждый день на протяжении уже многих лет и до сих пор пишут действия как методы класса контроллера, так что это плохой довод, знаете ли.
То есть Вы решили проигнорировать ссылки, которые я оставил? Что мешает использовать composer, PSR, неймспейсы в Yii? Хороший разработчик — разработчик, который понимает, что он делает. Yii никак не мешает Вам использовать современные стандарты и технологии. То, что официальная документация Вам об этом не говорит, конечно проблема, но Вы же программист, а значит должны уметь думать. Очень плохо, что наши разработчики отказываются от размышлений и не могут в самостоятельность…
Посмотрите все-таки ссылки, которые я оставил и подумайте еще разок)
И поймете, что Yii 1 куда лучше, чем кажется. Его главная проблема в том, что официальная документация приучает к «плохим практикам и архитектуре». Мне, как разработчику на ZF2 довольно приятно работать с Yii 1, ведь он достаточно гибкий для того, чтобы использовать лучшие практики и при этом позволяет довольно быстро прототипировать и сосредотачиваться на главном, беря контроль в свои руки только тогда, когда это действительно нужно.
Это о том, что он не выдерживает никакой критики — критикуйте, а я позащищаю, посмотрим, выдерживает, или нет ;)
НО! В целом я согласен, что в эпоху Laravel, Yii 2, Symfony 2 выбор неоправдан для такого проекта.
Спасибо за статью, то что мне было нужно! Работать с ним пока не собираюсь, ZF2 полностью устраивает, а вот для того чтобы поиграться и посмотреть фреймворк для общего развития — то что надо. И примеры есть и простор для дальнейшего творчества
elm-lang.org/guide/interop
www.slant.co/topics/1515/compare/~elm_vs_purescript_vs_haste
Ой, как я люблю так говорить!
мимобэкенд-разработчик
И это повальная проблема в разработке ПО. Мы берем фреймворки для разработки простых вещей, используем ООП для написания чего-то, что с легкостью укладывается в процедурную парадигму и так далее.
А для меня музыка это звуки, а код в душе. Об этом можно спорить бесконечно. У TDD-подхода есть одна важная обратная сторона — очень часто на выходе получается говно, потому что разработчик пишет так, чтобы проходило придуманные тесты, не сосредотачиваясь на том, КАК оно их проходит. Короче, для применения TDD нужне немалый опыт разработки, иначе это просто модное слово в списке используемых методологий, которое к тому же мешает разработке качественного кода.
Сразу вспомнил одну компанию, в которой довелось работать. Там было 4 разработчика, включая лида, все сидели в одном кабинете. Но мы каждое утро и вечер проводили stand-up митинги, отжирая час рабочего времени и каждую пятницу играли в planning poker, который, кстати, никогда не соответствовал реальности, но затрачивали на него часа 3-4, а в особо запущеных случаях весь. А компания делала свои собственные, не очень большие сайты.
Это просто к примеру мешающего «модного слова» в списке используемых модных слов. Потом перешел в компанию, где, несмотря на то, что народу было больше, не страдали фигней, а писали код. На прошлом месте за 3 месяца так ничего и не доделали до конца, на новом с нуля за месяц онлайн игру, выдерживающую 10к юзеров онлайн.
Это я все про Веб, если что, как в других сферах не знаю, но в веб все очень печально с этим. И разговор не о веб-студиях…
Ну и еще с Вашими рекомендациями можно не согласиться во многих местах, но это уже выше в Комментах сделали.
Ок, допустим я занимался 2-3 года разработкой сервера для многопользовательской онлайн игры и использовал кучу крутых технологий, при этом понятия не имею о MySQL. Элементарная, казалось бы вещь, я непригоден для работы с Вами и не достоин быть middle-разработчиком?
И еще раз повторюсь про ваши критерии высказав такую точку зрения: куда более важно не что знает человек, а как он знает. И под «как» я подразумеваю образ мышления. А в эпоху легкодоступной информации в google многие знания(самый яркий пример — bootstrap) вообще ненужны — понадобилось, зашел в доки, быстро пробежал, бац, бац — готово. Всегда поражало, когда меня спрашивали заню ли я jQuery — что там мне ЗНАТЬ-то нужно?
Вы меня совсем не читаете что ли? Я ни разу не убеждал вас, что Yii 1 лучше хоть чего-то. Я лишь говорил о том, что он не так плох, как вы думаете.
С этим никто не спорит
Что, простите? Какой еще темы про Yii 2? С чего вы взяли, что я что-то путаю? Я прекрасно понимаю разницу и даже написал об этом выше.
Если об этом говорить, то кодстайл в Yii2 тоже не лишен недостатков
Я Вас поздравляю, я не работаю каждый день с Yii1 и сайты для себя на Yii2 не пишу, но это не меняет абсолютно ничего, к чему вы это? Я знаю людей, которые работают с yii1 каждый день на протяжении уже многих лет и до сих пор пишут действия как методы класса контроллера, так что это плохой довод, знаете ли.
Посмотрите все-таки ссылки, которые я оставил и подумайте еще разок)
github.com/clevertech/YiiBoilerplate
habrahabr.ru/post/211739/
И поймете, что Yii 1 куда лучше, чем кажется. Его главная проблема в том, что официальная документация приучает к «плохим практикам и архитектуре». Мне, как разработчику на ZF2 довольно приятно работать с Yii 1, ведь он достаточно гибкий для того, чтобы использовать лучшие практики и при этом позволяет довольно быстро прототипировать и сосредотачиваться на главном, беря контроль в свои руки только тогда, когда это действительно нужно.
Это о том, что он не выдерживает никакой критики — критикуйте, а я позащищаю, посмотрим, выдерживает, или нет ;)
НО! В целом я согласен, что в эпоху Laravel, Yii 2, Symfony 2 выбор неоправдан для такого проекта.