Думаю, это относится к любому php-фреймворку (несмотря на то, что yii, особенно второй мне очень нравится, но надо быть объективным).
Любая CMS большую часть времени тратит на самоподъем. Фреймворки просто работают на более низком уровне, предоставляя при этом большую гибкость.
Для любого сколько нибудь крупного проекта фреймворк, так же предпочтительнее и разработки на чистом php, поскольку все равно придется организовывать код, а так хорошо, как это сделано в фреймворке сделать все равно вряд ли получится, плюс время на наработку такого «библиотечного» кода потратится много.
Статью обязаны читать все «заказчики». По опыту переубедить делать серьезный проект не на «Битриксе» или «Друпале» порой бывает очень сложно. Теперь просто буду давать ссылку )
Если нет ресурсов «пилить» нормальный (в смысле специально под ваши запросы) движок, то поставьте Битрикс Малый бизнес и наймите хорошего разработчика чтобы он все грамотно настроил.
Спасибо всем за развернутые комментарии.
Решил, что Laravel буду тоже щупать. Вообще, чем больше фреймворков использовать, тем лучше — при взгляде с разных сторон более объективная картина складывается.
Очень интересен опыт сравнения Yii и Lavarel.
Правильно ли я понимаю, что вы работали с первой версией Yii? Или удалось пощупать и вторую версию?
Laravel, думаю, не зря так резво набирает популярность. Интересно ваше мнение — почему?
Анализировал фреймворки для миграции с Zend'а (работал с ним с версии 0.7 и вторая версия откровенно разочаровала). Меня в Lavarel'e оттолкнула некоторая его «винигретность» — по ощущениям, надергано компонент из фреймворков и создается ощущение, что нет целостности и это все не способно работать идеально.
Yii 2 же после Zend'а мне кажется просто песней (не потому, что Zend был плох, а потому, что он скорее был основой для разработки своего фреймворка — все, что нужно надо было писать самому, а он только предоставлял инструменты). Часто слышу похожие сравнения Lavarel с Yii (типа «Yii хорош, и вы будете любить его пока не попробуете Laravel»). Что, несомненно, интригует.
Если есть реальный опыт разработки на обоих этих фреймворках — расскажите, в чем преимущества?
Работал по интернет-магазину в свое время очень много.
Основное правило — не считайте покупателей дураками и делайте свое дело честно. Тогда все получится.
Работать надо много, заниматься раскруткой, отдача придет со временем. Ну либо бюджеты нужны совсем другие (на 600т.р. и раскрутить как следует и в товар вложиться сложно).
Честно — меньше думайте о моделях и подходах — больше о покупателях.
Потому, что в интернет-магазине главное — репутация.
Работаю на фреймворках много и давно, в рунете Yii хотят в большинстве проектов. Начинал использовать фреймворки с ZF и сейчас на нем найти работу гораздо сложнее, чем на Yii.
Yii и проще для старта. Я бы тоже с него рекомендовал начать.
Самая большая проблема с введением KPI — это «обратный эффект». Вместо того, чтобы работать по принципу «делай что должен», работники начинают подстраиваться под коэффициенты. Цель становится не делать работу хорошо, а делать работу так, чтобы получать хорошие коэффициенты.
А спланировать коэффициенты в веб-девелопменте (это все-таки не продажи и не конвеер) очень сложно и шанс при формальном подходе действуя по «лекалам» наказать невиновных и поощрить недостойных очень высок, а это моментально дает обратный эффект демотивации.
Пример из реальной жизни — знакомые разработчики писали систему, заказчик говорит, все, конечно, хорошо работает, но вот размер exe как-то подозрительно мал. Наверное, все сделано плохо. Итог: «оки» и в следующий раз ему выдали уже в два раза больший файл, полученный включением в проект бесполезного, но весьма объемного файла. Показатели достигнуты? Да. Результат такой был нужен? Сомневаюсь.
Уверен, что KPI — полезная система, но пока не слышал ни одного рецепта в веб-разработке, который бы мне захотелось применить у себя. Встречаются какие-то дикие — количество пройденных тестов, количество багов, прибыль по каждому сотруднику, и даже (omg!) количество строк кода — это все, по моему, какой-то дикий ужас.
Наверное можно внедрить какую-то первоначальную схему и итерационно оптимизировать, но на себе эксперементировать не хотелось бы.
Кто аргументирует «за» — дайте реальный пример. Буду с радостью использовать у себя (не иронизирую, реально ищу схему мотивации). Пока же рассматриваю только как дополнительный механизм для наведения порядка, да и то не использую (мне кажется наоборот, небольшой беспорядок даже лучше для процесса веб-разработки, чем жестко регламентированный и формальный подход).
Думаю это очень хороший метод — оценивать работу не сотрудника, а группы/команды. Поскольку команда способна к самоорганизации на том уровне, который расписать и просчитать нереально. Спасибо за идею.
Машины уже давно модульные, если что.
Есть платформы (просто их гораздо больше, чем компьютерных) и есть компоненты, благодаря чему запчасти часто взаимозаменяемы.
Ну и, конечно, в первую очередь это возможность «воткнуть» в свой телефон то, что массово производители никогда бы не стали внедрять во все аппараты ввиду отсутствия массового спроса.
Какое-нибудь измерительное оборудование, например.
Сторонние производители получат возможность подключиться к разработке и возможности открываются просто фантастические.
Я очень хорошо помню это время, поскольку сам был таким энтузиастом. Видео менял раз в месяц, например )
Ну изначально менять можно было что угодно (даже процессоры поддерживали совместимость), но я говорю об архитектуре PC, которая позволяла расширять систему посредством установки дополнительных компонентов с использованием стандартного интерфейса/разъема.
Сторонние производители под это наплодили целый парк устройств (видеокарты, звук, сеть,...), что, как мне кажется, и привело к доминированию платформы на рынке. Эппл тоже свою платформу похоронил и с 2006 года свои компы делает на базе PC-архитектуры. Сейчас, по сути, другой платформы и не осталось.
Выдержка из вики:
> К 1984 году IBM-совместимых компьютеры выпускали более 50 компаний, а в 1986 году объём продаж клонов превысил собственный объем продаж фирмы IBM. Архитектура IBM PC завоевала весь мир: никакой другой фирме, будь то Apple Macintosh, NeXT, Amiga или другим, не удалось занять место рядом с IBM.
Сейчас просто идет второй виток спирали. То, что стало монолитным теперь становится снова модульным. Уже на новом уровне.
А мне кажется, за модульностью большое будущее.
Pivot, например, уже делает модульные очки-камеру — очень удобно можно комбинировать возможности девайса.
Как в свое время PC занял лидирующие позиции, так и модульные устройства будут иметь конкурентные преимущества перед «монолитом».
Из плюсов видится:
— можно адаптировать девайс «на ходу» — иногда важен емкий акк и не нужен блютус/вайфай, а иногда, наоборот. Иметь один проц и кучу обвеса выгоднее, чем несколько девайсов.
— можно апгрейдить частями.
— можно ремонтировать самому — замена компонент по сложности будет сопоставима с заменой аккумулятора.
— …
Если, конечно, дизайн не подкачает — все привыкли к хорошему дизайну.
Любая CMS большую часть времени тратит на самоподъем. Фреймворки просто работают на более низком уровне, предоставляя при этом большую гибкость.
Для любого сколько нибудь крупного проекта фреймворк, так же предпочтительнее и разработки на чистом php, поскольку все равно придется организовывать код, а так хорошо, как это сделано в фреймворке сделать все равно вряд ли получится, плюс время на наработку такого «библиотечного» кода потратится много.
Статью обязаны читать все «заказчики». По опыту переубедить делать серьезный проект не на «Битриксе» или «Друпале» порой бывает очень сложно. Теперь просто буду давать ссылку )
Оказалось, что, как обычно, изобретаю велосипеды. Очень похоже.
Решил, что Laravel буду тоже щупать. Вообще, чем больше фреймворков использовать, тем лучше — при взгляде с разных сторон более объективная картина складывается.
Правильно ли я понимаю, что вы работали с первой версией Yii? Или удалось пощупать и вторую версию?
Laravel, думаю, не зря так резво набирает популярность. Интересно ваше мнение — почему?
Анализировал фреймворки для миграции с Zend'а (работал с ним с версии 0.7 и вторая версия откровенно разочаровала). Меня в Lavarel'e оттолкнула некоторая его «винигретность» — по ощущениям, надергано компонент из фреймворков и создается ощущение, что нет целостности и это все не способно работать идеально.
Yii 2 же после Zend'а мне кажется просто песней (не потому, что Zend был плох, а потому, что он скорее был основой для разработки своего фреймворка — все, что нужно надо было писать самому, а он только предоставлял инструменты). Часто слышу похожие сравнения Lavarel с Yii (типа «Yii хорош, и вы будете любить его пока не попробуете Laravel»). Что, несомненно, интригует.
Если есть реальный опыт разработки на обоих этих фреймворках — расскажите, в чем преимущества?
Основное правило — не считайте покупателей дураками и делайте свое дело честно. Тогда все получится.
Работать надо много, заниматься раскруткой, отдача придет со временем. Ну либо бюджеты нужны совсем другие (на 600т.р. и раскрутить как следует и в товар вложиться сложно).
Честно — меньше думайте о моделях и подходах — больше о покупателях.
Потому, что в интернет-магазине главное — репутация.
Yii и проще для старта. Я бы тоже с него рекомендовал начать.
Только в пятницу уговаривал клиента потерпеть и остаться на бете, поскольку «уже RC2 и релиз не за горами».
Прямо подарок )
А спланировать коэффициенты в веб-девелопменте (это все-таки не продажи и не конвеер) очень сложно и шанс при формальном подходе действуя по «лекалам» наказать невиновных и поощрить недостойных очень высок, а это моментально дает обратный эффект демотивации.
Пример из реальной жизни — знакомые разработчики писали систему, заказчик говорит, все, конечно, хорошо работает, но вот размер exe как-то подозрительно мал. Наверное, все сделано плохо. Итог: «оки» и в следующий раз ему выдали уже в два раза больший файл, полученный включением в проект бесполезного, но весьма объемного файла. Показатели достигнуты? Да. Результат такой был нужен? Сомневаюсь.
Уверен, что KPI — полезная система, но пока не слышал ни одного рецепта в веб-разработке, который бы мне захотелось применить у себя. Встречаются какие-то дикие — количество пройденных тестов, количество багов, прибыль по каждому сотруднику, и даже (omg!) количество строк кода — это все, по моему, какой-то дикий ужас.
Наверное можно внедрить какую-то первоначальную схему и итерационно оптимизировать, но на себе эксперементировать не хотелось бы.
Кто аргументирует «за» — дайте реальный пример. Буду с радостью использовать у себя (не иронизирую, реально ищу схему мотивации). Пока же рассматриваю только как дополнительный механизм для наведения порядка, да и то не использую (мне кажется наоборот, небольшой беспорядок даже лучше для процесса веб-разработки, чем жестко регламентированный и формальный подход).
Есть платформы (просто их гораздо больше, чем компьютерных) и есть компоненты, благодаря чему запчасти часто взаимозаменяемы.
Какое-нибудь измерительное оборудование, например.
Сторонние производители получат возможность подключиться к разработке и возможности открываются просто фантастические.
Ну изначально менять можно было что угодно (даже процессоры поддерживали совместимость), но я говорю об архитектуре PC, которая позволяла расширять систему посредством установки дополнительных компонентов с использованием стандартного интерфейса/разъема.
Сторонние производители под это наплодили целый парк устройств (видеокарты, звук, сеть,...), что, как мне кажется, и привело к доминированию платформы на рынке. Эппл тоже свою платформу похоронил и с 2006 года свои компы делает на базе PC-архитектуры. Сейчас, по сути, другой платформы и не осталось.
Выдержка из вики:
> К 1984 году IBM-совместимых компьютеры выпускали более 50 компаний, а в 1986 году объём продаж клонов превысил собственный объем продаж фирмы IBM. Архитектура IBM PC завоевала весь мир: никакой другой фирме, будь то Apple Macintosh, NeXT, Amiga или другим, не удалось занять место рядом с IBM.
Сейчас просто идет второй виток спирали. То, что стало монолитным теперь становится снова модульным. Уже на новом уровне.
Pivot, например, уже делает модульные очки-камеру — очень удобно можно комбинировать возможности девайса.
Как в свое время PC занял лидирующие позиции, так и модульные устройства будут иметь конкурентные преимущества перед «монолитом».
Из плюсов видится:
— можно адаптировать девайс «на ходу» — иногда важен емкий акк и не нужен блютус/вайфай, а иногда, наоборот. Иметь один проц и кучу обвеса выгоднее, чем несколько девайсов.
— можно апгрейдить частями.
— можно ремонтировать самому — замена компонент по сложности будет сопоставима с заменой аккумулятора.
— …
Если, конечно, дизайн не подкачает — все привыкли к хорошему дизайну.
Желаю удачи с проектом.