Comments 245
Используете md5 для хэширования паролей
Объясните, в чем проблема? Как надо правильно делать?
PHPStorm?
wtf?
Zend? Symfony? Laravel? Yii, прости господи?
А, просто, папочка Vendor?
«why should not i use md5 for passwords» > Google
www.bentasker.co.uk/blog/security/201-why-you-should-be-asking-how-your-passwords-are-stored
www.bentasker.co.uk/blog/security/201-why-you-should-be-asking-how-your-passwords-are-stored
Вы вкусный наверное, надо попробовать!
Объясните, в чем проблема?
Для md5 легко подобрать коллизию. Лучше использовать bcrypt (хотя уже говорят что и это не ок, и нужно юзать scrypt но и bcrypt для большинства систем достаточно). Ну и можно погуглить почему медленные алгоритмы хэширования паролей лучше в контексте безопасности.
Как надо правильно делать?
password_hash, причем даже соль не нужно генерить руками, password_hash с этим прекрасно справится и сам. Возможно для некоторых случаев и стоит так делать но я не могу пока придумать зачем.
wtf?
Вот тут солидарен. PhpStorm няшка, но я знаю массу разработчиков которые перешли на vim, как раз для того что бы умный ide, в котором есть масса удобных штук, не подначивал делать плохо. Ну и да, vim многие настраивают под себя, и есть в принципе неплохие проекты реализующие сервер для автокомплита. VIM это круто. Хотя я еще не дорос… Для меня пока только phpstorm, netbeans и тд.
А, просто, папочка Vendor?
Не просто. Тут больше акцент внимания стоит выделить на том, что люди понимают зачем нужно использовать готовые решения типичных задач. То есть просто папочка vendor значит что вы используете composer. Круто. Но вот если вы, к примеру, используете какой-то пакет реализующий PSR-7 как слой абстракций над HTTP, то это уже круче.
Объясните, в чем проблема? Как надо правильно делать?
php.net/manual/ru/function.password-hash.php
php.net/manual/ru/function.password-verify.php
Это все хорошо, и это мы знаем, но PHP 5 >= 5.5.0
По собственному опыту php 5.5 стоит только у 30% пользователей, да вот такой парадокс.
До сих пор часто встречаю php 5.2 у пользователей, на хостинге.
Расскажите как тогда пользоваться функциями php 5.5 и выше, если у более 50% стоит 5.2, 5.3, 5.4
Как отправлять продакшн модули, с функциями 5.5 и выше?
По опыту тех. поддержки модулей с требованиями php 5.3 и выше, частенько встречаю «глупые» вопросы, «а почему у меня белый экран» и ничего не показывает
По собственному опыту php 5.5 стоит только у 30% пользователей, да вот такой парадокс.
До сих пор часто встречаю php 5.2 у пользователей, на хостинге.
Расскажите как тогда пользоваться функциями php 5.5 и выше, если у более 50% стоит 5.2, 5.3, 5.4
Как отправлять продакшн модули, с функциями 5.5 и выше?
По опыту тех. поддержки модулей с требованиями php 5.3 и выше, частенько встречаю «глупые» вопросы, «а почему у меня белый экран» и ничего не показывает
Мне, например, наплевать на существование шаред хостингов, а код я в последний раз продавал 16 лет назад и вообще не понимаю этого бизнеса. Клиентам нужно решение задач их бизнеса, а не какой-то там код, хостинг и прочая ерунда.
:)
E-commerce системы не решение задач для бизнеса?
Что «вы» все зацикливаетесь на обычных сайтах и совсем забываете о e-commerce бизнесе.
16 лет назад не было того, что сейчас. Сейчас очень бурно развивается направления «интернет-магазинов» обычными «домохозяйками». Где они хостятся? ;) Правильно на шаред хостингах. И хорошие модули (код) очень востребованы.
E-commerce системы не решение задач для бизнеса?
Что «вы» все зацикливаетесь на обычных сайтах и совсем забываете о e-commerce бизнесе.
16 лет назад не было того, что сейчас. Сейчас очень бурно развивается направления «интернет-магазинов» обычными «домохозяйками». Где они хостятся? ;) Правильно на шаред хостингах. И хорошие модули (код) очень востребованы.
Непонятно, зачем домохозяйке такие сложные технические манипуляции — для них есть shopify и подобные сервисы.
Серьезно? shopify? Для «домохозяек»?
Вы к примеру пробовали opencart? Я смотрю вы не особо в «теме» ИМ -в (без обид). Я понимаю у каждого своя специализация
Вы к примеру пробовали opencart? Я смотрю вы не особо в «теме» ИМ -в (без обид). Я понимаю у каждого своя специализация
Если пользоваться готовыми темами — вполне для домохозяек. Еще ecwid есть. Ну или всякие там wix.com (вроде там был примитивный e-commerce?), если уж для совсем-совсем домохозяек.
У opencart я видел исходный код, после чего все свои усилия сосредоточил на том, чтобы развидеть. :-)
У opencart я видел исходный код, после чего все свои усилия сосредоточил на том, чтобы развидеть. :-)
Идеального кода не бывает, но есть еще такое понятие как архитектура. По моему мнению она тоже не идеальна у opencart (мне очень многое не нравиться именно в архитектуре), но получше чем у существующих php e-commerce систем.
И как показатель, рост сообщества (очень не маловажный фактор для домохозяек), модулей, тем, сайтов на opencart. Здесь была статья, так вот, пару лет назад было в ру нете всего 5000 интернет-магазинов на opencart, а полгода назад уже насчитали 150`000.
И как показатель, рост сообщества (очень не маловажный фактор для домохозяек), модулей, тем, сайтов на opencart. Здесь была статья, так вот, пару лет назад было в ру нете всего 5000 интернет-магазинов на opencart, а полгода назад уже насчитали 150`000.
Архитектура opencart лучше, чем magento, SRSLY?
Впрочем, если он так популярен, дарю бизнес-идею — сделайте opencart SAAS. Если вы правы — неплохо можно заработать.
Впрочем, если он так популярен, дарю бизнес-идею — сделайте opencart SAAS. Если вы правы — неплохо можно заработать.
лучше, чем magento, SRSLY?
В целом да. Возможно за последние 2 года в магенту что-то поменялось но…
github.com/opencart/opencart/blob/master/upload/system/library/request.php
Архитектура, да.
Архитектура, да.
Лучше, потому что проще.
Поэтому и такая популярность у opencart — он прост (при очень большом функционале) для обычных пользователей и очень прост для разработчиков (читаем модули дешевле в 5 раз (это лучшие, которые must have, а простые так вообще раз в 10 дешевле) чем для magento)
И opencart в умелых руках — очень гибкий framework (да, не ослышались именно можно трактовать как fw, потому что уже имеет архитектуру а не просто куча кода)
Поэтому и такая популярность у opencart — он прост (при очень большом функционале) для обычных пользователей и очень прост для разработчиков (читаем модули дешевле в 5 раз (это лучшие, которые must have, а простые так вообще раз в 10 дешевле) чем для magento)
И opencart в умелых руках — очень гибкий framework (да, не ослышались именно можно трактовать как fw, потому что уже имеет архитектуру а не просто куча кода)
А что сейчас используют НЕ мамонты для того что бы следить за изменениями в базе данных?
А откуда могут взяться изменения в базе данных (речь про структуру БД) кроме тех, что внесли вы сами, как разработчик? У вас есть некий Нафаня, который по ночам залезает в БД и нещадно добавляет поля и индексы?
Есть команда, которая может удалять/добавлять поля/индексы итп. Всё это под контролем версий понятное дело. Разработчики всегда в курсе что твориться со структурой базы во время разработки, посредством конечно-же до боли знакомым всем — миграциям.
Мой вопрос был о том что в качестве системы миграций используют НЕ мамонты.
Мой вопрос был о том что в качестве системы миграций используют НЕ мамонты.
Что угодно. От файлов типа 0001_up.sql и 0001_down.sql и баш-скрипта, который умеет их скормить БД, до систем миграции, встроенных в используемый фреймворк. Особой разницы нет.
Смысл лишь в том, что все изменения в БД должны быть под контролем системы контроля версий. Как конкретно это реализовано — не так уж и важно, идеальной реализации еще не написано.
Смысл лишь в том, что все изменения в БД должны быть под контролем системы контроля версий. Как конкретно это реализовано — не так уж и важно, идеальной реализации еще не написано.
Тоже озаботился этим вопросом для legacy проекта на днях. И вот, разрешите вам представить — phinx.
В Symfony проектах это doctrine migrations, куда же без них.
В Symfony проектах это doctrine migrations, куда же без них.
Кажется, Вы тот кто понял мой вопрос. Огромное спасибо!
Хотя у нас и не Symfony проект, а ZF используем doctrine migrations и это как-то ужасно… Посмотрю на phinx, возможно подключим его.
Хотя у нас и не Symfony проект, а ZF используем doctrine migrations и это как-то ужасно… Посмотрю на phinx, возможно подключим его.
А какие у вас проблемы с миграциями доктрины?
Возможно такие, что я неправильно их готовлю… Не особо в этом разбирался, миграции достались в наследство вместе с проектом. Попросту говоря, сейчас, это простой phar который всем управляет… Но что мне не нравится, так это то что достукаться до модулей приложения я не могу. Использовать такой же сахар, как скажем, в phinx тоже нет… Да и постоянные проблемы вылазят во время этих же миграций… То оно примененную миграцию в свою же таблицу записать не может, то ещё что-то…
Я уже присматриваюсь к phinx. Вроде, очень не плохо всё сделано. На досуге еще дополнительно почитаю и попробую интегрировать.
Я уже присматриваюсь к phinx. Вроде, очень не плохо всё сделано. На досуге еще дополнительно почитаю и попробую интегрировать.
Честно говоря подобных проблем не испытывал все время использования миграций. Да, у них есть ограничения, но не все они именно доктриновские. В MySQL, к примеру, если миграция рушится на изменении схемы (во время отладки, положим), то схема останется в полуразобранном состоянии. Это особенность MySQL (и MS SQL Server тоже). Postgres же корректно откатывает все изменения.
Что касается доступа к модулям — есть ContainerAwareMigration которая по-идее как раз эту проблему и решает (если я правильно понял).
А проблема вставок в свою же таблицу это скорее всего результат «грязной» разработки — вмешательства в служебные таблицы «ручками», удаление миграций после их выполнения, неполный откат при фэйлах, разница в схемах в разных окружениях и т.д.
Я бы рекомендовал все-таки попробовать разобраться, провести рефакторинг и научиться готовить. Phinx конечно интересен, но он прежде всего ориентирован на проекты без ORM.
Что касается доступа к модулям — есть ContainerAwareMigration которая по-идее как раз эту проблему и решает (если я правильно понял).
А проблема вставок в свою же таблицу это скорее всего результат «грязной» разработки — вмешательства в служебные таблицы «ручками», удаление миграций после их выполнения, неполный откат при фэйлах, разница в схемах в разных окружениях и т.д.
Я бы рекомендовал все-таки попробовать разобраться, провести рефакторинг и научиться готовить. Phinx конечно интересен, но он прежде всего ориентирован на проекты без ORM.
В простом коде, когда отлаживаешь — отлично работают транзакции и конструкции try… catch. Не знаю почему это беда для миграций
Спасибо за наводку на ContainerAwareMigration. Обязательно посмотрю что это за зверь.
А ORM и нет :) Всё что от доктрины — миграции. По-этому phinx тут как раз кстати.
Спасибо за наводку на ContainerAwareMigration. Обязательно посмотрю что это за зверь.
А ORM и нет :) Всё что от доктрины — миграции. По-этому phinx тут как раз кстати.
As you wish =)
Oracle?
В простом коде, когда отлаживаешь — отлично работают транзакции и конструкции try… catch. Не знаю почему это беда для миграций
ок, ваша транзакция отработала на половину, выкинулся эксепшен, как вы будете откатывать изменения? При разработке ладно, а вот при деплое на боевые серваки могут быть проблемки.
Спасибо за наводку на ContainerAwareMigration.
Не самая хорошая идея, использовать сервисы для миграций. Хотя иногда случается что нужно, но ооочень редко.
ок, ваша транзакция отработала на половину, выкинулся эксепшен, как вы будете откатывать изменения? При разработке ладно, а вот при деплое на боевые серваки могут быть проблемки.
Отработала на половину, значит делаем полный rollback и сообщаем о эксепшене. Соответственно ничего и не мигрируем до момента пока не исправим.
Не самая хорошая идея, использовать сервисы для миграций. Хотя иногда случается что нужно, но ооочень редко.
У меня как раз тот случай когда надо. Сервисы содержат методы со сложными выборками. Переписывать эти выборки или дублировать код ради этих целей — как-то не очень.
Согласен с подходом автора примерно на 95%. Спасибо, порадовали и дали дополнительный повод подумать, а не сожрут ли меня завтра...?
> и не боитесь переносить логику во внешние ключи, триггеры и процедуры.
а если я не боюсь, но и не переношу?
ммм, как у вас организованы миграции для триггеров и для процедур?
а вообще слишком агрессивно
а если я не боюсь, но и не переношу?
ммм, как у вас организованы миграции для триггеров и для процедур?
а вообще слишком агрессивно
Согласен, слишком агрессивно. Все зависит от проекта, еще больше зависит от заказчика и уж почти все зависит от денег которые заказчик вам платит. Если мне друг вася дает бутылку за то, чтобы я ему сделал лендинг, я естественно не буду делать под это репозиторий. Если большой проект который подразумевает рост то безусловно все в git.
git репозиторий я бы все равно создал, тк это не сложно и скорее облегчит процесс разработки даже однодневного проекта. А вот CI, авто-деплой и прочее разворачивать смысла точно нет.
А что там «разворачивать»-то?
Сценарий вида «скопируй конфиги, накати миграции, переключи симлинк» пишется за 15 минут. И сам по себе является документацией для процесса выкладки.
Шаг сборки в TeamCity вида «выполни этот сценарий при изменении в master» — еще 5 минут.
Итого 20 минут, а в результате — отсутствие каких-либо проблем с деплоем.
Сценарий вида «скопируй конфиги, накати миграции, переключи симлинк» пишется за 15 минут. И сам по себе является документацией для процесса выкладки.
Шаг сборки в TeamCity вида «выполни этот сценарий при изменении в master» — еще 5 минут.
Итого 20 минут, а в результате — отсутствие каких-либо проблем с деплоем.
а если я не боюсь, но и не переношу?
Возможно, Вам это не нужно? ОК, не вопрос. Главное — понимать как это делать, если вдруг понадобится.
ммм, как у вас организованы миграции для триггеров и для процедур?
Вы не поверите!
$this->execute('CREATE PROCEDURE ...');
Можете предложить более красивый вариант — с удовольствием поучусь.
я к этому и спрашивал, что процедура и триггер не атомарные объекты и для них нужны отдельные способы миграции (например хранить полные тексты, тогда изменения не должны потеряться).
но имхо бизнес логика размазанная на 2 уровня (приложение и базу) это зло
но имхо бизнес логика размазанная на 2 уровня (приложение и базу) это зло
бизнес логика размазанная на 2 уровня (приложение и базу) это зло
Позвольте не согласиться. Что же злого, к примеру, во view, которая нами сделана, чтобы агрегировать статистику по какому-то параметру и разрезу? А это бизнес-логика, на минуточку. Или вы предлагаете в таких случаях вытаскивать все данные в приложение и обрабатывать? Зачем? База данных по определению лучше справится с данными.
Это зло, если система миграций не позволяет отслеживать, что и где (и какого черта) поменялось в базе и сравнивать с продакшеном то, что должно в итоге получиться. И добро (относительное) в некоторых проектах при условии, что ваша система миграции не допускает потери изменений или рассинхронизаций ни при каких обстоятельствах.
вообще странный у вас какой-то выбор, сделать VIEW или вытащить все данные, а что SQL запросы уже отменили?
обычные view это просто sql запрос смысл зашивать его в базу, если с БД у вас работают только машины? ещё и отдельные способы миграции для них придумывать
> База данных по определению лучше справится с данными.
не по определению, а в большинстве случаев. и да бывают задачи где лучше вытащить все данные (скорее определенную порцию, но не суть) и обработать их в приложении.
ну и изначально разговор был про триггеры и хранимки
обычные view это просто sql запрос смысл зашивать его в базу, если с БД у вас работают только машины? ещё и отдельные способы миграции для них придумывать
> База данных по определению лучше справится с данными.
не по определению, а в большинстве случаев. и да бывают задачи где лучше вытащить все данные (скорее определенную порцию, но не суть) и обработать их в приложении.
ну и изначально разговор был про триггеры и хранимки
Товарищ прав про то, что view — это гадость, кстати. Потому что во view жестко зашит список колонок. Когда нужно добавить новую колонку в ту или иную таблицу, приходится альтерить и все (или многие) view, которые таблицу используют — по крайней мере, при активной разработке и и развитии проекта именно так и происходит подчас.
А когда-то на Хабре были и сиськи по пятницам…
legacy-код — это не проблема кода, а проблема вашей лени
Имеется в виду лень уволиться с сытного, но «технологически отсталого» места? Или всё таки это намёк, что нужно изучать технологии без реальных задач?
Имеется в виду, что проверка совместимости кода со следующей версией PHP достаточно тривиальна. А адаптация — незатратна.
Нет ни одной причины работать на 5.3 или старше даже в случае легаси. Создайте тестовый стенд. Ловите каждую ошибку и отправляйте в свой любимый таск-трекер через его API. День на автоанализатор кода, благо все несовместимости тщательно задокументированы. Неделю потратьте на ручное тестирование сомнительных мест или написание тестов — смотря что Вам ближе. Не торопясь исправляйте найденные ошибки.
Лень? А получить фактически бесплатный прирост производительности в 2-3 раза не лень?
Нет ни одной причины работать на 5.3 или старше даже в случае легаси. Создайте тестовый стенд. Ловите каждую ошибку и отправляйте в свой любимый таск-трекер через его API. День на автоанализатор кода, благо все несовместимости тщательно задокументированы. Неделю потратьте на ручное тестирование сомнительных мест или написание тестов — смотря что Вам ближе. Не торопясь исправляйте найденные ошибки.
Лень? А получить фактически бесплатный прирост производительности в 2-3 раза не лень?
VCS, миграции, сборки… Все так, но причем тут PHP?
А вообще «тест Джоэля» о том же, только лучше. Хоть и был создан 15 лет назад.
А вообще «тест Джоэля» о том же, только лучше. Хоть и был создан 15 лет назад.
VCS, миграции, сборки… Все так, но причем тут PHP?
В целом неплохому языку не повезло. Неверное позиционирование, лишняя консервативность, низкая планка входа.
Отсюда низкий в среднем (!) уровень разработчиков, выражающийся в незнании современных инструментов разработки и пренебрежении ими.
Поэтому для многих именно PHP-программистов некоторые слова и термины из теста станут открытием.
Господа, а поясните пожалуйста что не так с array()?
Ну по-моему
$a=[];
лучше смотрится :)
$a=[];
лучше смотрится :)
И все?
2 символа вместо 7. К тому же скобки () пишутся с шифтом, а в случае [] без шифта. Какие преимущества у array()?
Подсветка. Не заметно, один параметр передается в функцию или несколько.
$this->someMethod($foo, $bar);
$this->someMethod([$foo, $bar]);
$this->someMethod(array($foo, $bar));
Я не сказал что у array() есть преимущества. Мне действительно интересно, может я чего-то не знаю.
не обращайте внимания, это для товарищей, которые под программированием подразумевают 8-ми часовое ежедневное печатание на клавиатуре.
Отсутствие преимуществ уже есть недостаток. Ну и потом, именование массива тоже может попасть под код-стайлы, у вашего array() шансов никаких против [] в этом случае.
Преимущества array() — поддержка большим числом версий PHP, включая все еще распространную версию 5.3.
Например, если вы делаете приложение, предполагающее установку на серверах клиентов, то лучше иметь в требованиях инсталляции как можно более широкий диапазон версий.
Например, если вы делаете приложение, предполагающее установку на серверах клиентов, то лучше иметь в требованиях инсталляции как можно более широкий диапазон версий.
Вы были бы безусловно правы, если бы различия между 5.3 и 5.6 на array() и заканчивались. Но так как это не так, то это не очень-то и преимущество.
php5.3 увы больше не поддерживается, да и суппорт 5.4 скоро дропнут. Лучше стимулировать спрос хостингов с более новыми версиями php.
p.s. Лично я не пользуюсь услугами шаредов, как по мне VDS намного лучше и удобнее.
p.s. Лично я не пользуюсь услугами шаредов, как по мне VDS намного лучше и удобнее.
Как пользователь шаредов хочу добавить, что даже отечественные второсортные хостинги уже давно имеют на борту хоть и не 5.6, но 5.5 точно. Так что «популярные 5.3» — это лишь отговорка. А если и нет, то стоит побыстрее бежать оттуда, всё же «фиксы безопасности», коих нет в 5.3 (и скоро не будет в 5.4) — это не пустой звук.
а меня-то за что минусуете? xD
Каждый раз, когда я вижу такие тесты, моя рука как-то сама тянется к пистолету.
Как известно, нет более рьяных фанатиков, нежели новообращённые. Вычитал священную истину? Срочно вызубри её и понеси дальше. Задумываться при этом необязательно, от Священных постулатов исходит самоочевидный ореол непререкаемой мудрости.
Дорогой топикстартер! Пожалуйста, запомни одну простую вещь: использование любого инструмента в первую очередь должно быть адекватно задаче. И во вторую тоже. А не тому, что написали в очередной умной книжке.
Ну вот из самого очевидного:
> Ну сколько раз повторять — ВСЁ ДОЛЖНО БЫТЬ В GIT-Е!
Очевидно, всегда можно придумать множество примеров того, что не должно быть в гите. Зачем повторять капсом?
Приватные ключи разработчиков не должны быть в гите, например.
> Каждой задаче — своя ветка
Зачем? Средство должно быть адекватно задаче, не наоборот. Если стоит задача поправить документацию — зачем ей своя ветка? Чтобы что?
> Любая ветка рано или поздно будет влита в стабильную (тем или иным путём) и/или удалена
Например, дев-ветка с кастомными настройками проекта никогда не будет влита в стабильную и/или удалена.
> Или считаете себя умнее всех и написали свой велосипед для выкладки релизов?
Надо же, куда не посмотри — везде свой велосипед для выкладки релизов:
cloud.google.com/appengine/docs/python/tools/uploadinganapp
devcenter.heroku.com/articles/deploying-php
developers.openshift.com/en/managing-deployments.html
С нетерпением жду, когда Гугл, Хероку и Редхат вымрут, как мамонты.
> если вы постоянно работаете более, чем с одним современным фреймворком
Представьте себе, бывают ситуации, когда фреймворки более вредны, нежели полезны.
В частности, при разработке SDK, поскольку сторонняя библиотека не должна ни тащить за собой кучу левого кода, ни навязывать свой фреймворк разработчику.
> Плюс еще 5, если вас хотя бы однажды посещала мысль «До чего же криво в этом фреймворке реализовано X, я бы переделал» или плюс 15 баллов, если вы взяли и переделали.
Картинка «Situation: we have 15 competing standards».jpg
> Вы хотя бы раз в жизни выбирали сервер БД исходя из бизнес-требований к будущему приложению (и остановились на Postgres, не так ли?). Вы отчетливо понимаете, что в общем случае каждый JOIN — это вложенный цикл, прекрасно знаете, что правильные индексы и некривые запросы дадут для производительности гораздо больше, чем шардинг и балансировка нагрузки, не считаете NoSQL панацеей и смеетесь над идеей применять MongoDB в качестве основного хранилища реляционных по своей природе данных.
Отличный пример двоемыслия в одном абзаце. «Исходя из бизнес-требований к приложению», но «прекрасно знаете» и «смеётесь над идеей». Оооок.
> Много вкусного мяса! «Мням-мням-мням» — слышите, как щелкают челюсти ваших конкурентов? Сожрут-с, однако.
Я не стал считать свои баллы. Подожду, пока меня сожрут.
Как известно, нет более рьяных фанатиков, нежели новообращённые. Вычитал священную истину? Срочно вызубри её и понеси дальше. Задумываться при этом необязательно, от Священных постулатов исходит самоочевидный ореол непререкаемой мудрости.
Дорогой топикстартер! Пожалуйста, запомни одну простую вещь: использование любого инструмента в первую очередь должно быть адекватно задаче. И во вторую тоже. А не тому, что написали в очередной умной книжке.
Ну вот из самого очевидного:
> Ну сколько раз повторять — ВСЁ ДОЛЖНО БЫТЬ В GIT-Е!
Очевидно, всегда можно придумать множество примеров того, что не должно быть в гите. Зачем повторять капсом?
Приватные ключи разработчиков не должны быть в гите, например.
> Каждой задаче — своя ветка
Зачем? Средство должно быть адекватно задаче, не наоборот. Если стоит задача поправить документацию — зачем ей своя ветка? Чтобы что?
> Любая ветка рано или поздно будет влита в стабильную (тем или иным путём) и/или удалена
Например, дев-ветка с кастомными настройками проекта никогда не будет влита в стабильную и/или удалена.
> Или считаете себя умнее всех и написали свой велосипед для выкладки релизов?
Надо же, куда не посмотри — везде свой велосипед для выкладки релизов:
cloud.google.com/appengine/docs/python/tools/uploadinganapp
devcenter.heroku.com/articles/deploying-php
developers.openshift.com/en/managing-deployments.html
С нетерпением жду, когда Гугл, Хероку и Редхат вымрут, как мамонты.
> если вы постоянно работаете более, чем с одним современным фреймворком
Представьте себе, бывают ситуации, когда фреймворки более вредны, нежели полезны.
В частности, при разработке SDK, поскольку сторонняя библиотека не должна ни тащить за собой кучу левого кода, ни навязывать свой фреймворк разработчику.
> Плюс еще 5, если вас хотя бы однажды посещала мысль «До чего же криво в этом фреймворке реализовано X, я бы переделал» или плюс 15 баллов, если вы взяли и переделали.
Картинка «Situation: we have 15 competing standards».jpg
> Вы хотя бы раз в жизни выбирали сервер БД исходя из бизнес-требований к будущему приложению (и остановились на Postgres, не так ли?). Вы отчетливо понимаете, что в общем случае каждый JOIN — это вложенный цикл, прекрасно знаете, что правильные индексы и некривые запросы дадут для производительности гораздо больше, чем шардинг и балансировка нагрузки, не считаете NoSQL панацеей и смеетесь над идеей применять MongoDB в качестве основного хранилища реляционных по своей природе данных.
Отличный пример двоемыслия в одном абзаце. «Исходя из бизнес-требований к приложению», но «прекрасно знаете» и «смеётесь над идеей». Оооок.
> Много вкусного мяса! «Мням-мням-мням» — слышите, как щелкают челюсти ваших конкурентов? Сожрут-с, однако.
Я не стал считать свои баллы. Подожду, пока меня сожрут.
Помимо приватных ключиков я бы ещё вытащил из гита продакшн конфиги и вендорные папочки, плюс всякие бинарники (например редис, тарантул, сфинкс, которые бывают хранятся локально вместе с проектом), плюс конфиги иде (.idea, .iml, etc.) тоже не стоит отправлять в гит. Всякий кеш тоже однозначно в игнор, включая tmp папочку с сессиями.
Этот список можно продолжать ещё долго, но результат один — автору статьи стоит вычесть у себя 5 баллов. =)
Этот список можно продолжать ещё долго, но результат один — автору статьи стоит вычесть у себя 5 баллов. =)
на счет .idea я бы поспорил. .idea/workspace.xml стоит игнорить, а все остальные настройки скорее всего понадобятся и остальным разработчикам.
Вполне возможно, только там зархардкожены пути так, что проще перенастроить, начиная с Command Line Tools плагина, заканчивая композером и старт-командами. Полезную информацию можно выдрать разве что о каталогах (что скрыто, что ресурсы, что сырцы, что ещё что-либо).
Больше я не представляю чего там полезного может быть, что прописано не в виде абсолютного пути.
Больше я не представляю чего там полезного может быть, что прописано не в виде абсолютного пути.
Не, продакшн-конфиги должны лежать в отдельном git-е.
в принципе конфиги должны лежать в отдельной репе + какой нить ансибл/шеф для развертывания дев/продакшен нод, как и конфигов из гита нужных.
На сложных проектах быстро получить прод/дев окружение на физике или виртуалке достаточно сложно — слишком много иногда зависимостей — сервер бд, редис, кафки, кассандры, а развернуть какойнить pyenv с тремя разными версиями питона потому что кусок купленного сто лет назад продукта — легаси еще вполне живет на питон 2.6, и будет жить еще с полгода пока пилится next-gen version приложения.
На сложных проектах быстро получить прод/дев окружение на физике или виртуалке достаточно сложно — слишком много иногда зависимостей — сервер бд, редис, кафки, кассандры, а развернуть какойнить pyenv с тремя разными версиями питона потому что кусок купленного сто лет назад продукта — легаси еще вполне живет на питон 2.6, и будет жить еще с полгода пока пилится next-gen version приложения.
Как известно, нет более рьяных фанатиков, нежели новообращённые.
Если вы это в мой адрес, Вы слегка ошиблись. Я первый коммит кода, написанного на PHP, сделал лет 10 назад, еще на PHP 4.
А вот Вы слишком серьезно относитесь к тому, что в интернете кто-то неправ (с)
> А вот Вы слишком серьезно относитесь к тому, что в интернете кто-то неправ (с)
Разве я пишу на Хабр статьи про то, что всё должно быть в гите?
Разве я пишу на Хабр статьи про то, что всё должно быть в гите?
Разве Вам кто-то запрещает?
Во-первых это всё-таки пятничный пост. Во-вторых, поверьте, всё-таки проще сначала ввести общее правило, а уже потом добавлять к нему исключения, нежели пойти обратным путём.
Общее правило — «Всё в гите». Правило вводится в теории, но не ввести его нельзя.
Удачно подмеченные Вами исключения — это служебные файлы IDE, приватные ключи (собственно, а кому пришла такая идея в голову?), пароли в открытом виде, папка vendor (это бессмысленно, достаточно хранить composer.json, всё равно при сборке всё будет тянуться заново), папки ресурсов и прочее, что в .gitignore и так далее. Исключения постигаются на практике.
Не вижу противоречия между шуточно-серьёзным тестом и вашим комментарием. Они прекрасно дополняют друг друга, за что мы и любим Хабр.
Во-первых это всё-таки пятничный пост. Во-вторых, поверьте, всё-таки проще сначала ввести общее правило, а уже потом добавлять к нему исключения, нежели пойти обратным путём.
Общее правило — «Всё в гите». Правило вводится в теории, но не ввести его нельзя.
Удачно подмеченные Вами исключения — это служебные файлы IDE, приватные ключи (собственно, а кому пришла такая идея в голову?), пароли в открытом виде, папка vendor (это бессмысленно, достаточно хранить composer.json, всё равно при сборке всё будет тянуться заново), папки ресурсов и прочее, что в .gitignore и так далее. Исключения постигаются на практике.
Не вижу противоречия между шуточно-серьёзным тестом и вашим комментарием. Они прекрасно дополняют друг друга, за что мы и любим Хабр.
Желательно помимо composer.json таскать composer.lock, даже не желательно, а более чем рекомендательно. И ставить всё через composer install.
Тоже верно. Впрочем, на тестовых стендах можно и composer update запустить. Лишним не будет.
А еще лучше делать composer install на билд-машине, а на серверы притаскивать готовый tarball со всеми зависимостями.
Composer install на продакшене допустимым считаю, только если поднят свой packagist, и все зависимости лежат на своем сервере. Иначе может и github прилечь, и packagist — всякое случается (вон, недавно китайцы github ддосили), такие вещи не должны останавливать деплой.
Composer install на продакшене допустимым считаю, только если поднят свой packagist, и все зависимости лежат на своем сервере. Иначе может и github прилечь, и packagist — всякое случается (вон, недавно китайцы github ддосили), такие вещи не должны останавливать деплой.
Приватные ключи разработчиков не должны быть в гите, например.
ну я к примеру храню их в git (зашифрованными в gpg), и доступ к содержимому архива есть только у меня. На каждый сервер генерируется свой ключ и что бы не потерять оный, и легко было заменить, лучше хранить в git. По поводу приватных штук (креды к внешним api и т.д.) — так же есть варианты, в зависимости от того что используется для деплоймента.
Вы копаете ямы обычной лопатой, а не лопатой с супер черенком 7.0?
Вы используете лопату нажимая ногой, а не втыкая с разворота?
Вы не используете в работе 2-3 инновационные лопаты одновременно?
Вы не делаете тестовых ям, чтобы потом накатить на основную яму?
У вас все еще нет автоматических тестов устойчивости для вашей ямы?
Вы обречены… другие ямы поглотят вас!
Вы используете лопату нажимая ногой, а не втыкая с разворота?
Вы не используете в работе 2-3 инновационные лопаты одновременно?
Вы не делаете тестовых ям, чтобы потом накатить на основную яму?
У вас все еще нет автоматических тестов устойчивости для вашей ямы?
Вы обречены… другие ямы поглотят вас!
Интересно было бы увидеть список успешных бизнесов, победивших конкурентов за счет немамонтовости в разработке.
Ну там Гугл например?
победивших конкурентов за счет немамонтовости в разработке.
немамонтовость разработки дает несколько другие вещи:
— предсказуемость (git-flow, continuous delivery)
— уменьшение затрат на поддержку (популярные готовые решения, пусть они и не идеальны, всегда лучше чем самописный велосипед)
— уменьшение затрат на изменение/внедрение нового функионала
Все это позволяет более гибко упровлять релизами и добавлять плюшки, доставлять пользователям больше ценности и за счет этого уже побеждать. На и да, можно просто жахнуть денег в маркетинг.
Вопрос немного в другом, стоит ли гнаться за всеми немамонтовыми фишками, новыми версиями языков и т.д. Ведь это деньги на переобучение, перестроение процессов или найм людей. Ведь с другой стороны, старые бизнес-процессы разработки тоже работали. Т.е. для крупных компаний окупаемость в несколько лет имеет смысл (или нет?), но всем поголовно?
Вот и хотелось бы увидеть сравнение нескольких компаний с конкурентами, ключевым фактором победы у которых было бы следование всем новым лучшим практикам.
Вот и хотелось бы увидеть сравнение нескольких компаний с конкурентами, ключевым фактором победы у которых было бы следование всем новым лучшим практикам.
Ведь это деньги на переобучение
Деньги на переобучение — возможно, как долгосрочная инвестиция, но проще найти новых разработчиков если все так уж плохо. Здравый смысл никто не отменял, нужно менять все постепенно. Обычно вводится одна плюшка, которая тянет за собой другую, потом третью. continuous improvement и все такое.
PHPStorm холивара ради?
«Неважно какой фреймворк вы используете, простейший механизм миграций в состоянии написать даже Junior за пару часов.»
1. Если мы говорим про изменение схемы — migrate down работает прекрасно. Но как только дело касается изменения данных — даже доктрина(как пример написанный не джуниором) бессильна сделать адекватный лог изменений. Приведу пример — у вас поле-флаг где часть записей имеют значение 0, а остальные 1. Миграция заменила все 0 в 1 запросом «UPDATE table SET flag=1». Как предлагаете реализовать откат? Без бэкапа перед деплоем не обойтись. А вот вопрос — не будет ли реализация migrate down избыточной при сохранения бэкапа?
2. Я прекрасно понимаю, зачем класть тех же вендоров в гит, но не могу придумать, зачем класть свои локальные настройки в гит?
3. В целом я согласен, что исползьование composer'а вне контекста фреймворка частенько сильно экономит время. Но это касается людей которые смотрят на фреймворки чуть глубже, чем на их документацию и примеры из stackoverflow.
1. Если мы говорим про изменение схемы — migrate down работает прекрасно. Но как только дело касается изменения данных — даже доктрина(как пример написанный не джуниором) бессильна сделать адекватный лог изменений. Приведу пример — у вас поле-флаг где часть записей имеют значение 0, а остальные 1. Миграция заменила все 0 в 1 запросом «UPDATE table SET flag=1». Как предлагаете реализовать откат? Без бэкапа перед деплоем не обойтись. А вот вопрос — не будет ли реализация migrate down избыточной при сохранения бэкапа?
2. Я прекрасно понимаю, зачем класть тех же вендоров в гит, но не могу придумать, зачем класть свои локальные настройки в гит?
3. В целом я согласен, что исползьование composer'а вне контекста фреймворка частенько сильно экономит время. Но это касается людей которые смотрят на фреймворки чуть глубже, чем на их документацию и примеры из stackoverflow.
Есть ровно два подхода.
1. Вы запрещаете откат такой миграции (что сводит на нет всю систему миграций, как истории изменений)
2. Вы не запрещаете откат, но он не производит никаких действий.
Третий вариант, когда откат поднимает прежние данные из бэкапа, не имеет смысла на боевой базе и может применяться разве что для отладки.
1. Вы запрещаете откат такой миграции (что сводит на нет всю систему миграций, как истории изменений)
2. Вы не запрещаете откат, но он не производит никаких действий.
Третий вариант, когда откат поднимает прежние данные из бэкапа, не имеет смысла на боевой базе и может применяться разве что для отладки.
- Нет, не сводит на нет. Лучше иметь возможность отката для большинства миграций, чем вообще её не иметь.
- Отличный способ получить напрочь сломанный проект в результате отката.
- Восстановление из бэкапа не так страшно для продакшна, как Вы расписываете. Во-первых бэкап нужно делать автоматически перед миграцией на новую версию. Таким образом, если с новой версией обнаружатся проблемы, то скорее всего это случится в течении минут, максимум часов после обновления, и восстановление из бэкапа приведёт к потере минимума данных. Во-вторых если только это не реально большой проект с HA и избыточными серверами то он в любом случае будет восстанавливаться из бэкапов если умрёт винт. Так что если это будет происходить не раз в 3-5 лет, а раз в год-два из-за ошибок девелоперов при выкатывании новой версии — никакой трагедии в этом нет.
> Во-первых бэкап нужно делать автоматически перед миграцией на новую версию
ну да, желательно полный, и пофиг что он будет сутки делаться и пока он будет делать там ещё данных набежит.
> и восстановление из бэкапа приведёт к потере минимума данных
вот честно я не знаю примера реальной продакшен базы кроме логов которые можно похерить не то что за часы, а даже за минуты
ну да, желательно полный, и пофиг что он будет сутки делаться и пока он будет делать там ещё данных набежит.
> и восстановление из бэкапа приведёт к потере минимума данных
вот честно я не знаю примера реальной продакшен базы кроме логов которые можно похерить не то что за часы, а даже за минуты
он будет сутки делаться и пока он будет делать там ещё данных набежитНу дык бэкапы тоже нужно правильно делать.
Данные нужно организовывать так, чтобы те таблицы, которые реально большие и которые полностью бэкапить слишком долго, были инкрементальными — т.е. чтобы в них делался только INSERT, без UPDATE/REPLACE/DELETE (на самом деле DELETE тоже можно для компактификации, но это делается отдельно). Это позволит сделать полный бэкап только для небольших таблиц, а для больших сделать инкрементальный бэкап только новых записей (более того, если эта миграция не будет делать ALTER этим большим таблицам то можно вообще просто запомнить id последней строки и реально бэкапить интервал нужных строк этих таблиц уже после завершения миграции на новую версию).
При таком подходе бэкап большинства даже весьма крупных проектов будет занимать секунды.
эм, а вы такой инкрементальный бекап сами настраивали? и если вдруг да, то восстановится потом пробовали?
это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходят.
большие бекапы работают, только если ваши данные (например вместе с серверами) физически уничтожены и это последний выход, когда можно потратить день-два тупо что-бы это всё развернуть.
это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходят.
большие бекапы работают, только если ваши данные (например вместе с серверами) физически уничтожены и это последний выход, когда можно потратить день-два тупо что-бы это всё развернуть.
Не только настраивал и использовал в продакшне годами, есть готовый фреймворк Narada для разработки и деплоя таких проектов — с поддержкой бэкапов, миграций, etc… Он сам написан на Perl+sh (устанавливается как обычный Perl-модуль), но разрабатывать проекты используя этот фреймворк можно на любом языке.
это какой-то очень специфичный кейс когда запись не может изменяться, мне опять только логи на ум приходятНет, дело не в кейсе и не в данных, а в способе их организации. Это аналогично тому, что для удобства тестирования требуется немного иначе писать код — в данном случае для удобства бэкапов требуется немного иначе работать с данными.
Типичный приём — колонки в таблице A, которые содержат большие объёмы данных (текстовый контент, json, блобы) выносятся в отдельную инкрементальную таблицу B, а в таблице A эти колонки заменяются колонками с id записей в таблице B. Это позволяет значительно уменьшить размер таблицы A и ускорить её (полный) бэкап. Любое изменение данных вынесенных в таблицу B реализуется добавлением новой записи в таблицу B и изменением её id в таблице A. Для уменьшения размера базы можно периодически удалять все записи в B на которые больше нет ссылок в A и делать полный бэкап B.
Это несколько усложняет код и добавляет лишний (но очень быстрый т.к. работает по primary key) JOIN в некоторые запросы, но зато даёт возможность бэкапить проект в течении пары секунд. Что в свою очередь даёт возможность блокировать проект на время бэкапа фактически незаметным для пользователей образом (задержка ответа на пару секунд мало заметна). Что даёт возможность атомарно делать консистентные бэкапы включающие файлы/логи/настройки/базы проекта. Плюс такие блокировки дают возможность так же атомарно обновлять проект. В общем, если взвесить все недостатки и преимущества такого подхода незначительное усложнение при работе с некоторыми колонками в базе оказывается вполне приемлемым.
из-за ошибок девелоперов при выкатывании новой версии
Это невозможно при грамотно построенном воркфлоу. Например в моем текущем случае без визы QA и человека от бизнеса на препродакшне никакая выкатка на прод невозможна физически. И более того — девелоперы вообще не имеют доступа к процессам деплоя.
Задача проходит три стенда — изолированный, интеграционный и предпродакшн. Во всех случаях деплой полностью автоматический и ручное вмешательство крайне нежелательно. Право же нажать кнопочку Run на продакшне есть только у специально обученного человека, а сама кнопка не появится без получения двух виз, о которых я говорил выше.
Это всё прекрасно, но у абсолютного большинства проектов, к сожалению, нет даже staging, всё сразу идёт в продакшн. И в этом случае количество виз и специально обученные люди которые имеют право на выкатывание — хоть и уменьшают вероятность ошибки, но не сводят её к нулю.
Ну и кстати опыт показывает, что когда деплой делается несколько раз в день (разумеется, автоматизированно!), пусть даже по инициативе одного девелопера, это ведёт к меньшему количеству ошибок, чем когда он делается редко (т.е. с большим количеством изменений) но с участием виз и специально обученных людей.
Ну и кстати опыт показывает, что когда деплой делается несколько раз в день (разумеется, автоматизированно!), пусть даже по инициативе одного девелопера, это ведёт к меньшему количеству ошибок, чем когда он делается редко (т.е. с большим количеством изменений) но с участием виз и специально обученных людей.
Это всё прекрасно, но у абсолютного большинства проектов, к сожалению, нет даже staging, всё сразу идёт в продакшн
Так ровно на это пост и намекает. Зачем держать код задачи в отдельной ветке? Зачем писать сценарии сборки? Для того, чтобы отдельно тестировать!
Поверьте, для этого есть очень дешевые (и по деньгам и по времени) технологии и приёмы. Те, кто их не применяет — те сами себе злобные буратины и мамонты.
Ну и кстати опыт показывает, что когда деплой делается несколько раз в день… это ведёт к меньшему количеству ошибок, чем когда он делается редко
Подписываюсь. За исключением возможности девелоперу инициировать выкладку. Для меня это звучит абсолютным абсурдом.
со всеми пунктами согласен, но почему PHPStorm? Чем netbeans не угодил? Или просто скажите мне, что не может netbeans по сравнению со штормом и я скажу как это сделать.
Вызов принят!
1) Простенькое: Множественное выделение кода
2) Средненькое: Переименовывание класса, включая все зависимости от него
3) Чуть посложнее: Поиск по классам, так, например «So\An» найдёт класс «namespace Some; class Any» из всех сырцов (исключая скрытые)
4) Ещё более круто: Анализ composer.json с указанием установленной версии зависимости (из lock файла) прямо в коде composer.json?
5) Вообще верх крутости: Интеллектуальный поиск с автодополнением по Dependency Injection контейнерам, включая анализ аннотаций
1) Простенькое: Множественное выделение кода
2) Средненькое: Переименовывание класса, включая все зависимости от него
3) Чуть посложнее: Поиск по классам, так, например «So\An» найдёт класс «namespace Some; class Any» из всех сырцов (исключая скрытые)
4) Ещё более круто: Анализ composer.json с указанием установленной версии зависимости (из lock файла) прямо в коде composer.json?
5) Вообще верх крутости: Интеллектуальный поиск с автодополнением по Dependency Injection контейнерам, включая анализ аннотаций
расскажите про пятый пункт поподробнее, потому как DI контейнер только по аннотациям работает, сам PhpStorm конфиги не понимает. Вы каким-то плагино пользуетесь? В рамках какого-то фреймворка?
Не только с аннотациями, можно же ещё напрямую вытаскивать, например так: Container::get(Some::class)->…
Плагин, если не путаю — Symfony2 Plugin этим занимается. Совместим с Laravel (4,5), PHP-DI и наверняка с какими-нибудь плюшками симфони (доктриной, например).
Плагин, если не путаю — Symfony2 Plugin этим занимается. Совместим с Laravel (4,5), PHP-DI и наверняка с какими-нибудь плюшками симфони (доктриной, например).
PHP Annotations + Symfony Plugin (при открытии или в проекте надо выбрать фреймворк) + Symfony Clickable Views
UFO just landed and posted this here
Взгляд неандертальца. :-)
Мамонтов вы, конечно, сожрете, но совсем недалеко стоянка кроманьонцев с docker, heroku, devops, lean-kanban и macbook-ом с красивыми наклеечками.
Мамонтов вы, конечно, сожрете, но совсем недалеко стоянка кроманьонцев с docker, heroku, devops, lean-kanban и macbook-ом с красивыми наклеечками.
docker на макбуке с наклеечкой превращается в VirtualBox, хотя конечно если снести предустановленную фигню на макбуке и поставить операционную систему
Да хотя бы таким неандертальцем стать.
Сейчас приходится работать с проектами, где:
1. PHP 5.2 (а в особо глубоких местах и PHP4)
2. Один репозиторий SVN на всё, без веток. Поэтому, когда надо что-то быстро поменять, идём ручками по серверам и меняем, потому что в SVN лежит коммит, который пока ещё нельзя выкладывать
3. База данных — зачем? Пусть всё хранится в json-файликах, которые другой PHP через system('rsync..') разливает по серверам.
3.1 Ну и никто не знает, как чинить этот другой PHP в случаях, если он не работает.
4. А даже если и есть база, то зачем миграции? Давайте просто отправлять SQL-ки админу, а он их выполнит
5. Автоматические тесты — что это вообще?
6. Во вьюхе в зенде открыть json файлик, распарсить и вывести — это ок.
7.…
8. PROFIT
Извините, накипело.
Сейчас приходится работать с проектами, где:
1. PHP 5.2 (а в особо глубоких местах и PHP4)
2. Один репозиторий SVN на всё, без веток. Поэтому, когда надо что-то быстро поменять, идём ручками по серверам и меняем, потому что в SVN лежит коммит, который пока ещё нельзя выкладывать
3. База данных — зачем? Пусть всё хранится в json-файликах, которые другой PHP через system('rsync..') разливает по серверам.
3.1 Ну и никто не знает, как чинить этот другой PHP в случаях, если он не работает.
4. А даже если и есть база, то зачем миграции? Давайте просто отправлять SQL-ки админу, а он их выполнит
5. Автоматические тесты — что это вообще?
6. Во вьюхе в зенде открыть json файлик, распарсить и вывести — это ок.
7.…
8. PROFIT
Извините, накипело.
Сейчас приходится
Под дулом пистолета приходится?
Если вы понимаете, почему плохо то, о чём пишете — почему Вас нет на HH?
Присоединяюсь к вышевысказавшемуся.
Копошась (другого слова не подберу) в таких вот условиях, вы теряете время и отстаете от современных технологий. Если нет каких-то особенных связей с текущим местом (угроза расправы, з/п намного выше рынка, единственный работодатель в окрестностях, обет), то надо уходить. Хорошего опыта вы там не получите, о новых подходах не узнаете, потеряете инициативность и просто деградируете как специалист.
Не нужно, думаю, объяснять, что современный прикладной программист — это не только технологии непосредственно программирования, но и современный тулстэк, методологии работы с задачами и заказчиками и т.п.
Тем более с вакансиями положение неплохое.
Копошась (другого слова не подберу) в таких вот условиях, вы теряете время и отстаете от современных технологий. Если нет каких-то особенных связей с текущим местом (угроза расправы, з/п намного выше рынка, единственный работодатель в окрестностях, обет), то надо уходить. Хорошего опыта вы там не получите, о новых подходах не узнаете, потеряете инициативность и просто деградируете как специалист.
Не нужно, думаю, объяснять, что современный прикладной программист — это не только технологии непосредственно программирования, но и современный тулстэк, методологии работы с задачами и заказчиками и т.п.
Тем более с вакансиями положение неплохое.
Как раз есть особенные связи. Работаю системным администратором в Колумбии (которая не штат, а страна), тут всё тяжело в IT. А на этом месте работы и зарплата выше рыночной, и такую работу, где могут организовать визу, проблемно найти. В принципе, постепенно всё и тут двигается, стараюсь, внедряю и оптимизирую что могу. Но разруха — она в головах.
Зато остаётся время на фриланс и свои проекты, где всё более радужно:)
Зато остаётся время на фриланс и свои проекты, где всё более радужно:)
Нужны интересные вакансии (современный PHP, современные средства разработки, не сайтики) — стучитесь в личку. Думаю, договоримся.
Давайте лучше приколимся результатами, у меня 115 набралось ) больше из за git и велосипеда с deploy
Молодые мамонтята читают такие посты, подрастают и потом мы видим кучу бесполезного УГ, но с очень правильным и красивым бэкэндом. Странно что не упомянули о какой-нибудь модной методологии типа аджайла. Наверное, после постов типа «почему аджайл не работает» это уже не так модно? Видимо, надо написать ещё десяток статей а-ля «почему мой проект плох, ведь я хранил весь код в гите» или «почему товар в моём магазине не покупают, ведь его сайт написан на php версии over 9000».
Автор случаем не перепутал в тесте слова «знаете» и «используете»?
Знать все это перечисленное барахло — надо, использовать — только при необходимости.
Прошедшие тест люди нас будут изрядно пугать, потому что у них тупо отсутствует гибкость.
Основное качество адекватного разработчика.
Вброс с phpstorm особенно доставил, zend studio что, никто не использует из модных ребят?
Знать все это перечисленное барахло — надо, использовать — только при необходимости.
Прошедшие тест люди нас будут изрядно пугать, потому что у них тупо отсутствует гибкость.
Основное качество адекватного разработчика.
Вброс с phpstorm особенно доставил, zend studio что, никто не использует из модных ребят?
Пробовал разок Zend. Заткнулся на попытке создать проект из существующей папки, так до сих пор и висит одиноко ярлычок, даже опробовать не получилось. Готов с удовольствием выслушать как это сделать, попробовать то хочется, можно даже в личке, дабы не оффтопить.
Честно говоря, не поняли даже в чем именно у Вас затык.
Проект создается по старому принципу «создать проект — далее — далее — готово»:)
Правда у нас 8-ка, обновляться жаба душит, а ее вполне хватает.
Зенд не очень добр к ресурсам (тут да, жесть, при чем издревле, видимо из-за явы), поэтому перешли на него только с 8 версии (когда обзавелись достойным железом, до этого использовали nushpere phped), но на сейчас никаких проблем не испытываем.
p.s.: Если есть вопросы — пишите в личку, чем сможем поможем, но скорость не обещаем. Или можно на почту. admin@наш_ник_здесь.ru
Проект создается по старому принципу «создать проект — далее — далее — готово»:)
Правда у нас 8-ка, обновляться жаба душит, а ее вполне хватает.
Зенд не очень добр к ресурсам (тут да, жесть, при чем издревле, видимо из-за явы), поэтому перешли на него только с 8 версии (когда обзавелись достойным железом, до этого использовали nushpere phped), но на сейчас никаких проблем не испытываем.
p.s.: Если есть вопросы — пишите в личку, чем сможем поможем, но скорость не обещаем. Или можно на почту. admin@наш_ник_здесь.ru
Я вот несколько лет назад на DEVConf слушал выступление одного мальчика, который что-то там придумал со своими друзьями, а потом встал мужичек в зале и сказал примерно следующее — «Пока вы делали все по правилам и стандартам, писали доки и комментили код фирма [какая-то-фирма] выпустила продукт [название-продукта] и успешно его внедряет, так что думаю вам стоит бросить то, что вы делали и заняться чем-то другим». Так вот если у вас команда, есть готовый продукт и вы делаете рефакторинг для того чтобы клиенты не падали в обморок, то да, всё что писал ТС верно, но если вы реализуете идею то можно и спагетти-код и ничего в этом нет плохого.
Такая проблема чаще всего возникает из-за того, что разработчики сосредоточены на «красоте» проекта. Код ради кода, а не ради бизнеса. Насколько я понимаю, то «мамонт» в посте — это опытный разработчик, который не использует новые инструменты. Думаю, что у опытного разработчика, который использует эти инструменты и подходы, время на выполнение проекта не сильно увеличится. Я бы даже сказал, что многие инструменты больше помогают в дальнейшей поддержке проекта. Проблемы будут лишь у тех, кто про эти вещи узнал, но не правильно их применил. Так что эта история больше относится к людям, принимающим неоправданные решения с точки зрения бизнеса (обычно это лиды и ПМы).
время на выполнение проекта не сильно увеличится
Позвольте уточнить — оно радикально сократится. Хороший инструмент это тот, который снижает себестоимость (то есть уменьшает затраченное время). Поверьте, всё, что я перечислил в пятничном тесте, работает на снижение себестоимости. Если правильно применять.
Опять-таки надо разделять время на создание проекта и его дальнейшую поддержку. Часто решения «в лоб» по скорости разработки с нуля не сильно уступают некоторым подходам, которые вы описали. Зато на этапе поддержки (изменения функциональности) это может вылится в дикие трудозатраты и бессоные ночи(не всегда, но зачастую).
Комментарий про DEVConf скорее говорит про то, что иногда проще «по-древнему» запилить прототип, а если уже «выстрелит», то сделать по уму, чем потратить больше времени на то, что может просто не пригодиться в дальнейшем.
Комментарий про DEVConf скорее говорит про то, что иногда проще «по-древнему» запилить прототип, а если уже «выстрелит», то сделать по уму, чем потратить больше времени на то, что может просто не пригодиться в дальнейшем.
Хорошая стратегия — говнокод → рефакторинг → поддержка. Говнокод позволяет быстро запуститься и, если проект оказался востребованным, можно уже рефакторить, чтобы дальнейшая поддержка не превратилась в ад.
UFO just landed and posted this here
Почему без поддержки? О чём вы?
UFO just landed and posted this here
до или после рефакторинга?
Рефакторинг должен происходить в период разработки, по чуть чуть и часто. Тогда появление страшного легаси будет сведено к минимуму (совсем без него наверное никак, но это не должна быть вся система). Это конечно при условии что вам удалось объяснить руководству, ну или руководство само в курсе, что такое технический долг.
То есть типичный флоу — сделали фичу (максимально простая реализация если это возможно), порефакторили если видите необходимость (дублирование логики например) или хотя бы пометили что какие-то решения были приняты в угоду скорости разработки и помечаются как технический долг. Далее при разработке фич, как-то относящихся к проблемным местам, можно рефакторить, уменьшать технический долг. Некоторые закладывают определенный процент тасков связанных именно с техническим долгом на итерацию (например 80%-90% времени на разработку фич, и остаток на устранение технического долга, зависит от масштабов трагедии и необходимости.) Какие-то сложные вещи могут идти как отдельные таски и приоритизировать (например костыль который влияет на производительность, или еще чего).
UFO just landed and posted this here
ну то есть говнокод в продакшен мы не пускаем
Почему? Пускаем конечно, если этот говнокод выполняет свою работу. Конечно есть еще разница что именно вы понимаете под говнокодом.
не проще сразу сделать нормально
Ну если у вас сразу выходит нормально, и при том так, что в течении полугода все ваши решения были идеальны — то круто и славно. Но я не верю что такие люди существуют. В большинстве случаев ретроспектива решает как надо было делать правильно.
отдали набор фич в продакшен, тут клиент захотел новую фичу, похожую на имеющуюся. вот тут самое место рефакторингу, чтобы значит не копипастить, а подвести под обе фичи единую основу.
Именно так. Тут есть нюансы, рефакторить нужно часто и маленькими этапами, и фичи дробить надо на как можно более маленькие.
позволять себе говнокодить — не вижу, когда бы такая стратегия приносила профит
Что для вас говнокодить? Если код, как бы он не пах, покрыт тестами и удовлетворяет всем функциональным и нефункциональным требованиям, ну и он изолирован, то я не думаю что это плохой код и ему не место на продакшене. Иногда приходится идти на компромисы в угоду бизнесу. Все относительно конечно, но обычно страшные и пахнущие вещи сложно покрыть тестами.
А вот без тестов постоянный рефакторинг штука болезненная, и тогда ее откладывают уже по понятным причинам. Никто не хочет делать полное регрессионное тестирование на каждый чих.
Я смотрю ниже тему раскрыли :)
Зависит от размера проекта. Если для запуска достаточно пары ночей хакатона — да, наговнокодить уместно. Если же речь идет о неделях, хорошие практики только ускорят разработку — при условии, что уровень команды достаточно высокий.
«Хоть вы и говнокодите, не пишете доки и не комментите код, фирма [какая-то-фирма] уже выпустила продукт [название-продукта] и успешно его внедряет, так что думаю вам стоит бросить то, что вы делали и заняться чем-то другим».
Не всякий проект может позволить себе быть написанным говнокодерами. Не всегда выйти на рынок первым — значит победить. Не нужно делить мир лишь на черное и белое, как автор этого поста — «Всё в гит! Конфиги в гит! Или тебя съедят!»
Не всякий проект может позволить себе быть написанным говнокодерами. Не всегда выйти на рынок первым — значит победить. Не нужно делить мир лишь на черное и белое, как автор этого поста — «Всё в гит! Конфиги в гит! Или тебя съедят!»
А как же phpUnit и функциональные тесты?
Я вполне допускаю ситуацию, когда в реальном производстве именно юнит-тесты приходится писать крайне редко. Тестами покрыты библиотеки и ваш фреймворк — этого вполне достаточно в реальности.
А функциональные тесты пишет QA-инженер и его команда.
Впрочем, возможно, я слишком долго занимаюсь построением индустриальных команд разработки и идеализирую. Сорри.
А функциональные тесты пишет QA-инженер и его команда.
Впрочем, возможно, я слишком долго занимаюсь построением индустриальных команд разработки и идеализирую. Сорри.
> PHPStorm?
Спор насчет редакторов и\или ide переживет еще не одного грозного питекантропа.
И да, только ископаемые моллюски пишут исключительно на одном на php (или любом другом языке). Тем более используя php-специфичную ide. Почему использовать несколько разных ide плохо, объяснять я надеюсь не нужно.
Спор насчет редакторов и\или ide переживет еще не одного грозного питекантропа.
И да, только ископаемые моллюски пишут исключительно на одном на php (или любом другом языке). Тем более используя php-специфичную ide. Почему использовать несколько разных ide плохо, объяснять я надеюсь не нужно.
php-специфичную ide
Шторм не специфичен к PHP.
В остальном Вы, разумеется, совершенно правы.
WebStorm — не специфичен, а вот PhpStorm всё же чётко заточен под веб-разработку на PHP, а не на питоне, например.
Я бы ещё добавил, что пишут и могут писать — разные вещи. Практически для всех задач, которые мне приходится решать (в т.ч. и консольные приложения не для веба), php подходит отлично, чем я и пользуюсь. Но это не значит, что я не умею писать на других языках и не умею пользоваться другими IDE.
Я бы ещё добавил, что пишут и могут писать — разные вещи. Практически для всех задач, которые мне приходится решать (в т.ч. и консольные приложения не для веба), php подходит отлично, чем я и пользуюсь. Но это не значит, что я не умею писать на других языках и не умею пользоваться другими IDE.
PhpStorm всё же чётко заточен под веб-разработку на PHP
Гм. Прекрасно пишу в нем на HTML, CSS, XML, YAML, JS, SQL… Что я делаю не так?
Ну давайте всё же разделять язык программирования и среду для работы с ним, с языком разметки. Языки разметки, которые вы перечислили, успешно можно редактировать и в Java специфичных IDE, .NET и т.д. SQL так же достаточно универсальный язык запросов, который в том или ином виде поддерживается разными СУБД, а так же используется другими языками программирования.
Соглашусь с комментарием.
Но не с высказыванием, что Шторм только для PHP.
Но не с высказыванием, что Шторм только для PHP.
Для IDE веб-разработка на PHP не исключает работы с тем, что вы перечислили, но требует специфичной заточки под него. И, заметьте, я не писал «только» :)
Шторм — это IDEA с плагином PHP. Если Вы это считаете «заточкой», можно на этом закончить спор.
Большая часть IDE которые я знаю и использовал работают по той же схеме — основа + плагин. Спорить не буду, просто расскажите, пожалуйста, что же такое «заточка» в вашем понимании?
Это Вы ввели термин. Вам и рассказывать )))
Для меня фактически нет разницы между Штормом и той же IntelliJ IDEA в версии для Java (грешен, Java FX иногда балуюсь). Ну ОК, пара специфичных пунктов в меню разве что.
Поэтому я и удивился Вашим комментариям.
Для меня фактически нет разницы между Штормом и той же IntelliJ IDEA в версии для Java (грешен, Java FX иногда балуюсь). Ну ОК, пара специфичных пунктов в меню разве что.
Поэтому я и удивился Вашим комментариям.
Ок. Всё просто. Пример со стормом:
Есть WebStorm, который подойдёт для тех вещей, которые вы описали чуть выше, более чем. PhpStorm идёт с удобной работой с xdebug, phpunit, symfony, laravel, навигацией по классам, выбора различных версий интерпретатора для разных профилей тестов и ещё приличным количеством вещей, которые для разработки не на PHP вообще не нужны — это то, что я называю заточкой среды разработки под язык программирования. Брать PhpStorm не для работы с PHP — не вижу смысла впринципе ни по цене, ни по функциональности. Стоимость первого — $100, а второго $200.
Таким образом заточенной средой разработки под язык программирования можно назвать ту среду, основная задача которой упрощать работу с конкретным языком и его окружением.
Просто если вы не согласны с тем, что «Шторм только для PHP», в первую очередь уточните какой именно из вышеперечисленных стормов. А то получается, что мы можем говорить про разные вещи.
Есть WebStorm, который подойдёт для тех вещей, которые вы описали чуть выше, более чем. PhpStorm идёт с удобной работой с xdebug, phpunit, symfony, laravel, навигацией по классам, выбора различных версий интерпретатора для разных профилей тестов и ещё приличным количеством вещей, которые для разработки не на PHP вообще не нужны — это то, что я называю заточкой среды разработки под язык программирования. Брать PhpStorm не для работы с PHP — не вижу смысла впринципе ни по цене, ни по функциональности. Стоимость первого — $100, а второго $200.
Таким образом заточенной средой разработки под язык программирования можно назвать ту среду, основная задача которой упрощать работу с конкретным языком и его окружением.
Просто если вы не согласны с тем, что «Шторм только для PHP», в первую очередь уточните какой именно из вышеперечисленных стормов. А то получается, что мы можем говорить про разные вещи.
Отлично разрабатываю на node.js в PhpStorm. При чём использую не просто как редактор. Проект на годе полностью поддерживается в этом IDE.
Отлично разрабатываю на node.js в PhpStorm. При чём использую не просто как редактор. Проект на ноде полностью поддерживается в этом IDE.
UFO just landed and posted this here
Я один набрал 0 баллов?)
Махните бивнем, кто набрал столько же)
Махните бивнем, кто набрал столько же)
За PHPStorm + IdeaVim-плагин 15 баллов полагается? :-)
Или считаете себя умнее всех и написали свой велосипед для выкладки релизов?
А я вот взял и написал: deployer.org =)
Расскажите мне, «немамонты», как миграция БД справится с обновлением высоконагруженных серверов? И какую используете вы?
Прекрасно справляется. Если под «высоконагруженными» имеется ввиду «сделали таблицы на 100500 миллионов записей и надо сделать ALTER TABLE» — это, простите, ССЗБ, партиционировать надо.
Да, вопрос был именно про такую ситуацию, большая таблица, требуется добавить поле. Странная логика, партицировать ради того, что бы сделать крайне редко ALTER через миграцию. Просто есть адекватные способы сделать изменение такой таблицы (через создание копии и тригеры).
И, кстати, как именно партицирование спасёт?
И, кстати, как именно партицирование спасёт?
Я не знаю, для чего у вас эта таблица. Но если неочевидна польза от партиционирования, подозреваю, что какие-то логи; а логи стоило бы хранить в чем-то более подходящем, чем ориентированная на OLTP-операции РСУБД: скажем, Cassandra, ElasticSearch и т.п., — в зависимости от того, что потом с этим надо делать.
Кстати, создание копий и триггеров прекрасно делается миграцией, если уж на то пошло.
Кстати, создание копий и триггеров прекрасно делается миграцией, если уж на то пошло.
Это не совсем логи, в моём случае это координаты.
Спасибо, надо пробовать
Спасибо, надо пробовать
Используйте нормальные СУБД, в которых операция добавления/удаления/переименования колонки — легкая и не зависит от числа строк в таблице, а индексы можно навешивать асинхронно, не останавливая работу. (Подсказка: например, на букву П.)
Добавил бы:
— используйте нормальные БД, в которых операции изменения структуры могут быть обёрнуты в транзакции.
Подсказка: это не MySQL
— используйте нормальные БД, в которых операции изменения структуры могут быть обёрнуты в транзакции.
Подсказка: это не MySQL
К сожалению, в базе на букву П большинство операций ALTER TABLE вызывают блокировку ACCESS EXCLUSIVE.
О базе на букву М вообще говорить нечего, там с DDL плохо почти всё. :-)
О базе на букву М вообще говорить нечего, там с DDL плохо почти всё. :-)
Как же забавляют подобные рассуждения!
Прежде всего надо быть Программистом! И тут мантры в виде используемых инструментов и техник мало чем помогут. Тем более, когда это преподается в виде «используешь — ты крут, не используешь — мамонт — быстро в яму, и закопаем уже его!». Настоящий специалист использует инструменты исходя из своих потребностей, удобства работы и необходимости их применения в решаемой задаче.
Печально, что оценивается не талант программиста, а лишь набор инструментов. Но, как говорится, по одежке (набору используемых инструментов) только встречают, а провожают все же по уму.
Автору сего теста я желаю, чтоб у него прорвало в квартире батарею, канализацию, а на вызов явился сантехник, весь увешанный новомодными инструментами, с умными пространными рассуждениями, но капец какой криворукий, чтобы у него «руки выросли прям из жопы, и даже нифига не золотые».
Прежде всего надо быть Программистом! И тут мантры в виде используемых инструментов и техник мало чем помогут. Тем более, когда это преподается в виде «используешь — ты крут, не используешь — мамонт — быстро в яму, и закопаем уже его!». Настоящий специалист использует инструменты исходя из своих потребностей, удобства работы и необходимости их применения в решаемой задаче.
Печально, что оценивается не талант программиста, а лишь набор инструментов. Но, как говорится, по одежке (набору используемых инструментов) только встречают, а провожают все же по уму.
Автору сего теста я желаю, чтоб у него прорвало в квартире батарею, канализацию, а на вызов явился сантехник, весь увешанный новомодными инструментами, с умными пространными рассуждениями, но капец какой криворукий, чтобы у него «руки выросли прям из жопы, и даже нифига не золотые».
Продолжу тему. Работал на проекте с кучей «полезных» инструментов (wordpress, laravel, angularjs, git, jenkins, composer, bower, grunt, phinx, ant, последняя версия php и т.д.). Набор из целого спектра. Следуя логике из теста, работающие над этим проектом получили бы 200 баллов. Но вот не задача, проект не работал как хотелось: стал очень ресурсоёмкий, сложно поддерживался, на любую задачу требовал много человеко-часов, работал на магии и костылях, слабо развивался и в итоге не приносил ожидаемой прибыли.
Я это к тому, что инструменты созданы для человека — когда будет нужно, тогда и воспользуемся. Но никак не наоборот — если есть интсрумент, то его необходимо использовать.
Если у вас есть дрель, это же не означает, что дома нужно прорешетить все стены?
Я это к тому, что инструменты созданы для человека — когда будет нужно, тогда и воспользуемся. Но никак не наоборот — если есть интсрумент, то его необходимо использовать.
Если у вас есть дрель, это же не означает, что дома нужно прорешетить все стены?
Вы всё правильно сказали. Но пока не придумали хороший способ оценить талант, нет такого теста, который покажет X% «таланта». Поэтому часто приходится заменять тест на «талант» тестом на знание/умение.
Я б еще добавил 2 пункта:
— Использование PSR, как минимум PSR-2 внутри команды/проекта как единого стиля.
— Использование PHPDoc для всего. Хорошо не только в целях документации, но и для лучшей поддержки IDE Autocomplete и подсветки ошибок в случае неверных типов данных.
> Вы правильно используете современные системы контроля версий
> * Всё должно быть в git-е
> * Всё — это значит всё! И даже конфиги приложения
Здесь уместно добавить примечание: все, кроме паролей и токенов.
— Использование PSR, как минимум PSR-2 внутри команды/проекта как единого стиля.
— Использование PHPDoc для всего. Хорошо не только в целях документации, но и для лучшей поддержки IDE Autocomplete и подсветки ошибок в случае неверных типов данных.
> Вы правильно используете современные системы контроля версий
> * Всё должно быть в git-е
> * Всё — это значит всё! И даже конфиги приложения
Здесь уместно добавить примечание: все, кроме паролей и токенов.
В PSR есть одна странность: они не рекомендуют использовать подчерки для приватных и протектед-свойств, что не соответствует, например, стилю кодирования в Zend Framework и еще куче чего:
Method names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.
Это что вообще?
Method names SHOULD NOT be prefixed with a single underscore to indicate protected or private visibility.
Это что вообще?
Это стандарт. Выработанный сообществом.
Мне кажется, что наличие любого стандарта, пусть даже он вызывает вопросы, всё-таки лучше, чем его отсутствие. А Вам?
Мне кажется, что наличие любого стандарта, пусть даже он вызывает вопросы, всё-таки лучше, чем его отсутствие. А Вам?
Наличие стандарта, который Не вызывает вопросов, еще лучше.
Давайте разбираться.
1. Вначале были PEAR Coding Standards, еще в PHP4. Авторы — мейнтейнеры php, многие из которых были также авторами pear и pecl-модулей. PEAR используют сотни тысяч, если не миллионы сайтов. Pivate-члены начинаются с подчерка.
2. Потом Zend начал активничать и выпустил Zend Framework и Zend Framework Coding Standards. Авторы — прародители PHP. Zend Framework, кажется, был первым массовым фреймворком для PHP с таким высоким качеством исполнения (до него тоже были фреймворки, но они все были «наколеночными» — поправьте меня, если я ошибаюсь; кстати, сейчас уже, наверное, другие выбились в лидеры). Отдельные модули из Zend Framework используют сотни тысяч сайтов. Private и protected-члены начинаются с подчерка.
3. Есть такой язык, называется python (со змеей в логотипе). Он где-то раз в несколько менее популярен, чем PHP. В нем protected-методы очень жестко начинаются с подчерка, а private — даже с двух (sic!) подчерков. Хотя я, признаться, ни разу не видел в реальном коде двухподчеркнутых членов, но сам механизм языка устроен таким образом, что два подчерка подряд как бы привязывают член к его собственному классу, т.е. получается реально private. Мне кажется, два подчерка — это перебор, но, тем не менее, их даже в язык вшили.
И вот теперь приходит «сообщество», как вы говорите, и почему-то на github-е, а не на официальном сайте php, публикует PSR. Стандат в целом хороший, я сам его придерживаюсь почти во всем, но у меня остаются два вопроса к нему:
1. Почему так обошлись с префиксами-подчерками, отбросив тонну существущего кода, практик и стандартов, применявшихся до этого.
2. Почему на официальном сайте php нет упоминаний PSR (или есть? где?).
Давайте разбираться.
1. Вначале были PEAR Coding Standards, еще в PHP4. Авторы — мейнтейнеры php, многие из которых были также авторами pear и pecl-модулей. PEAR используют сотни тысяч, если не миллионы сайтов. Pivate-члены начинаются с подчерка.
2. Потом Zend начал активничать и выпустил Zend Framework и Zend Framework Coding Standards. Авторы — прародители PHP. Zend Framework, кажется, был первым массовым фреймворком для PHP с таким высоким качеством исполнения (до него тоже были фреймворки, но они все были «наколеночными» — поправьте меня, если я ошибаюсь; кстати, сейчас уже, наверное, другие выбились в лидеры). Отдельные модули из Zend Framework используют сотни тысяч сайтов. Private и protected-члены начинаются с подчерка.
3. Есть такой язык, называется python (со змеей в логотипе). Он где-то раз в несколько менее популярен, чем PHP. В нем protected-методы очень жестко начинаются с подчерка, а private — даже с двух (sic!) подчерков. Хотя я, признаться, ни разу не видел в реальном коде двухподчеркнутых членов, но сам механизм языка устроен таким образом, что два подчерка подряд как бы привязывают член к его собственному классу, т.е. получается реально private. Мне кажется, два подчерка — это перебор, но, тем не менее, их даже в язык вшили.
И вот теперь приходит «сообщество», как вы говорите, и почему-то на github-е, а не на официальном сайте php, публикует PSR. Стандат в целом хороший, я сам его придерживаюсь почти во всем, но у меня остаются два вопроса к нему:
1. Почему так обошлись с префиксами-подчерками, отбросив тонну существущего кода, практик и стандартов, применявшихся до этого.
2. Почему на официальном сайте php нет упоминаний PSR (или есть? где?).
PEAR мертв как раз во многом потому, что прародители PHP забросили усилия сообщества в виде PEAR и стали с нуля делать ZF, качество которого, кстати, поначалу было весьма сомнительным. Но сейчас это все уже не важно — инициативу взяло на себя сообщество «нового поколения», образованное прежде всего вокруг Symfony — и что там на официальном сайте php — уже не имеет значения, эти сообщества очень мало пересекаются. Весь современный тулчейн (за, наверное, единственным исключением в лице PhpUnit) )не имеет никакого отношения к мейнтенерам php, Zend-у и прочей старой гвардии. Меня тот же composer поначалу смущал «переизобретением» PEAR — но сейчас это уже не важно, это стандарт де-факто, а про PEAR помнят только мамонты :-).
Подчерки же придумали во времена PHP4, когда не было private/protected. Современный PSR code style мне как раз нравится приближенностью к Java.
Подчерки же придумали во времена PHP4, когда не было private/protected. Современный PSR code style мне как раз нравится приближенностью к Java.
Вначале были PEAR Coding Standards, еще в PHP4
Вот и ответ на Ваше недоумение. Язык развивается, стандарты тоже. Естественный и очень правильный процесс.
Почему так обошлись с префиксами-подчерками
Потому что они не нужны.
Согласен. В любых правилах могут быть исключения.
Вот пример как Yii2 Framework выкрутился, просто добавили свою надстройку для PSR-2:
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/ruleset.xml#L6
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/Sniffs/Properties/PrivatePropertiesUnderscoreSniff.php
Все самое хорошее от PSR-2, плюс несколько своих оптимизаций.
Меня радует вцелом тенденция, движение в сторону каких-то общих стандартов и договоренностей, когда большинство участников только выигрывает.
Вот пример как Yii2 Framework выкрутился, просто добавили свою надстройку для PSR-2:
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/ruleset.xml#L6
github.com/yiisoft/yii2-coding-standards/blob/master/Yii2/Sniffs/Properties/PrivatePropertiesUnderscoreSniff.php
Все самое хорошее от PSR-2, плюс несколько своих оптимизаций.
Меня радует вцелом тенденция, движение в сторону каких-то общих стандартов и договоренностей, когда большинство участников только выигрывает.
Использование PSR, как минимум PSR-2 внутри команды/проекта как единого стиля.
Может стоит ограничиться «использованием стандарта форматирования кода внутри всей команды»?
Как человек, активно использующий `ant` для скриптов сборки истинно говорю вам: поставьте за его использование отрицательный рейтинг (касаемо мира PHP, конечно)
Всегда считал, что Ant и phing — это одно и тоже. Разумеется, применяю phing. А в чем принципиальная разница?
ИМХО лучший инструмент для «сборки» — это «пришел новый разработчик, создал себе директорию, склонировал исходники — и тут же пошел в браузер, открыл, и у него все сразу же заработало». Т.е. лучший инструмент — отсутствие необходимости в таком инструменте. Этого можно добиться, да (единственное исключение — если вы делаете «коробочный» продук, с дистрибутивом, инсталлятором и т.д., но это относительно редкость).
Какой-то идеальный и нереальный пример. Зачем этого нужно добиваться?
— вот более реальный вариант, которого мне неоднократно удавалось «добиться». При этом build.xml — самодокументируемый скрипт, он расскажет пытливому разработчику всё о том, как происходит сборка проекта.
- Склонировал проект
- Набрал в консоли phing
- Открыл браузер и получил полнофункциональную рабочую копию
— вот более реальный вариант, которого мне неоднократно удавалось «добиться». При этом build.xml — самодокументируемый скрипт, он расскажет пытливому разработчику всё о том, как происходит сборка проекта.
Самый реальный вариант — это запустить vagrant up. :-) Почти любой нетривиальный проект требует определенного нестандартного окружения.
Можете привести пример — что Вы имеете в виду под нестандартным окружением?
У меня, скажем, в предыдущем проекте был собственный extension, написанный на php-cpp, в текущем — FDW для postgresql.
Мой аргумент такой: если у вас сразу все работает после клонирования репозитория, то, значит, вы можете и исходники править «на лету» и тут же их обратно пушить в репозиторий. Т.е. репозиторий, исходники и работающий проект — суть одно и то же как бы. Если же у вас репозиторий+исходники — это одно, а файлы рабочего проекта — это другое, то возникают накладные расходы на ту или иную сихронизацию одного с другим.
Или вы имеете в виду, что сборка никогда не трогает исходники (и веб-сервер работает именно с теми же исходниками, которые склонировали из репозитория), а занимается чем-то еще? Можете привести пару конкретных примеров?
Или вы имеете в виду, что сборка никогда не трогает исходники (и веб-сервер работает именно с теми же исходниками, которые склонировали из репозитория), а занимается чем-то еще? Можете привести пару конкретных примеров?
PHPStorm?
Пробовал, не понравилось.
Пишу на Lua и PHP в Komodo Edit.
Зря вы. Любое мнение против PHPStorm смертельно в сфере Web-разработки.
UFO just landed and posted this here
… и страшные лаги на крупных проекта, а так же долгий старт, ну и конечно же необходимость подстраивать код под среду, дабы она могла правильно определять тип переменных и возвращаемых значений, можно еще вспомнить насилующие мизинец комбинации клавишь (ctrl+shift+tab+enter+a) или сложнейшую модель разработки плагиов, разобраться в которой сложнее, чем слетать в космос, а так да, прекрасная среда.
Обновите железо, ну или хотя-бы SSD добавьте.
Зачем? Меня мое железо вполне устраивает.
Зачем?
страшные лаги на крупных проекта, а так же долгий старт
Ну так я не пользуюсь PHPStorm, меня эти страшные лаги не касаются.
UFO just landed and posted this here
Он не такой требовательный, хотя в нем нельзя откинуться на спинку кресла, съездить из одной точки в другую за куда более короткий промежуток времени, перевозить одновременно несколько пассажиров или багаж
А если вам все это не нужно, то?
Но возмущаться тем, почему ради мощности иногда приходится жертвовать скоростью или ресурсами
Что такого мощного в PHPStorm, что он позволяет себе лагать на компьютере, на котором другие среды чуствуют себя хорошо?
Не скажу насчёт мощного, зато в нем есть ВСЁ, что может потребоваться для разработки на php.
— Браузер \ Restful service
— Управление базами
— FTP, VCS
— Тесты
— Различный диплой
— Консоль
— Поддержка Vagrant, SSH соединений, тунели
— все прелести вашего комодо|sublime|atom|другого текстового редактора
— и т.д. и т.п.
Я не опровергаю наличие других хороших IDE, но тем не менее PhpStorm я счёл лучшим для себя.
— Браузер \ Restful service
— Управление базами
— FTP, VCS
— Тесты
— Различный диплой
— Консоль
— Поддержка Vagrant, SSH соединений, тунели
— все прелести вашего комодо|sublime|atom|другого текстового редактора
— и т.д. и т.п.
Я не опровергаю наличие других хороших IDE, но тем не менее PhpStorm я счёл лучшим для себя.
Внимательно трижды прочёл Ваш комментарий, но не понял, что Вы имели в виду вот этим:
О чём речь?
ну и конечно же необходимость подстраивать код под среду, дабы она могла правильно определять тип переменных и возвращаемых значений
О чём речь?
Никогда не сталкивались с тем, что PHPStorm подсвечивает рабочий код как ошибку только потому, что не может распознать тип? Или нет возможности перейти к объявлению метода/класса?
В 9-ке почти все проблемы, с этим связанные, исправили. WI-12654 только мешает немного, но это редкий кейс.
В любом случае, в остальных IDE всегда было еще хуже.
В любом случае, в остальных IDE всегда было еще хуже.
Что будет, если я сделаю так:
PHPStorm определит переменную $obj как объект класса MyClass, или MyTrait?
Я не сравниваю PHPStorm, я говорю о его недостатках.
trait MyTrait{
function getInstance(){
return new self;
}
}
class MyClass{
use MyTrait;
}
$obj = MyClass::getInstance();
PHPStorm определит переменную $obj как объект класса MyClass, или MyTrait?
В любом случае, в остальных IDE всегда было еще хуже.
Я не сравниваю PHPStorm, я говорю о его недостатках.
ну собственно вот: youtrack.jetbrains.com/issue/WI-17671
можно флеш моб устраивать
а вообще напишите
return new static();
это будет понято правильно + больше соответствует поведению self/static вне трейтов
можно флеш моб устраивать
а вообще напишите
return new static();
это будет понято правильно + больше соответствует поведению self/static вне трейтов
а вообще напишите
return new static();
А какая разница? Все равно PHPStorm не определит тип.
вы думаете я от балды написал, чтоли?
habrastorage.org/files/60e/fbf/722/60efbf722ce048d8a0b6d38a2fcddec4.jpg
habrastorage.org/files/60e/fbf/722/60efbf722ce048d8a0b6d38a2fcddec4.jpg
Нисколько, я вам верю, но то лишь пример, думаю вы сами знаете случаи, когда PHPStorm не может распоздать тип.
ну честно с типами все очень даже хорошо, например у свойства будет правильный тип:
public $container;
public __construct(ContainerInterface $container) {
$this->container = $container;
}
единственное когда в аннотации написано не всё. то да лишнего он не добавит. Просто в силу природы динамичности php без подсказок тут нельзя
а так большинство моих issue они позакрывали, я где-то с 5 версии уже не сижу активно на их баг-трекере, так что меня в принципе всё устраивает
public $container;
public __construct(ContainerInterface $container) {
$this->container = $container;
}
единственное когда в аннотации написано не всё. то да лишнего он не добавит. Просто в силу природы динамичности php без подсказок тут нельзя
а так большинство моих issue они позакрывали, я где-то с 5 версии уже не сижу активно на их баг-трекере, так что меня в принципе всё устраивает
Антипаттернами не увлекаюсь:-), так что не сталкивался — но вообще тут должен помочь хинт return $this. Не идеально, но не вижу ничего страшного написать это 1 раз в трейте.
У меня минус 15 баллов, обледенелые мамонты охраняются законом.
Всё — это значит всё! И даже конфиги приложения
Как-то опасно звучит, особенно для тех кто далек от систем контроля версий. По-моему
основной конфиг-файл, который подключает приложение, должно быть в игноре, но рядом должен лежать пример этого файла (без логинов и паролей!!!).
/config.php — в игнор
/config.template.php — пример
А так в пуб репозитарии попадут пароли или долго будут гадать как сделать у себя на машине и на продакшн разные пароли и логины…
Я бы свел статью к
«Все прикручиваете модули к CMS? Откройте для себя Мэтта Зандру и Symfony Book».
Не так категорично и подталкивает людей к (хорошим, добрым, вечным) лучшим практикам.
«Все прикручиваете модули к CMS? Откройте для себя Мэтта Зандру и Symfony Book».
Не так категорично и подталкивает людей к (хорошим, добрым, вечным) лучшим практикам.
переносить логику во внешние ключи, триггеры и процедуры
Вот здесь автору 0.
А так отличный чек-лист, спасибо!
А? Чё? А за что вам минус то влепили? Триггеры и процедуры — зло! Лишь в очень редких случаях их использование может быть оправдано.
Вот кстати на прошлом проекте в базе было более десятка триггеров, без VCS, без миграций и без доков. Как много кайфа я испытал :sarcasm:.
Проблемы которые я увидел:
— Что-то магическим способом происходит, как — хз.
— Вылетает ошибка, мейл об ошибке не отсылается, да и логгер её не видит. Ручками заходим на сервер и идём в логи базы.
— Под Убунтой так и не нашёл GUI для их редактирования. (кто знает — подскажите)
— Об их существовании постоянно забывается. Правится код, правятся модели — но работает не так. WAT?!.. **** Триггеры, точно!
Вот кстати на прошлом проекте в базе было более десятка триггеров, без VCS, без миграций и без доков. Как много кайфа я испытал :sarcasm:.
Проблемы которые я увидел:
— Что-то магическим способом происходит, как — хз.
— Вылетает ошибка, мейл об ошибке не отсылается, да и логгер её не видит. Ручками заходим на сервер и идём в логи базы.
— Под Убунтой так и не нашёл GUI для их редактирования. (кто знает — подскажите)
— Об их существовании постоянно забывается. Правится код, правятся модели — но работает не так. WAT?!.. **** Триггеры, точно!
К сожалению, минусовавший свои аргументы не озвучил. Логику в триггерах ни тестами не покроешь, ни контроль версий нормальный не сделаешь, ну и про остальные прелести вы уже написали.
использую plv8 для постгреса в хранимках и триггерах. Есть приблуда для отладки, но мне хватает console log. Тестировать можно как угодно — есть юнит тесты через тестовую ноду (вывод в qunit на клиенте), behavior тестируется также как и везде, там вообще не принципально что на бэке. Контроль версий — через дамп структуры базы в git-e.
На вопрос про редкий случай, где они нужны. Ну не так уж и редко. Быстрый мультапдейт у меня на тригере, журналируемые таблицы тоже, очень удобно — повесил тригер и таблица сама хранит историю своих изменений, не надо это учитывать в сто пятиста местах внесения изменений данных в коде.
Расскажите мне пожалуйста, где я должен начать страдать, а то я себя обделенным чуствую.
p.s. минус не мой был, если что :)
На вопрос про редкий случай, где они нужны. Ну не так уж и редко. Быстрый мультапдейт у меня на тригере, журналируемые таблицы тоже, очень удобно — повесил тригер и таблица сама хранит историю своих изменений, не надо это учитывать в сто пятиста местах внесения изменений данных в коде.
Расскажите мне пожалуйста, где я должен начать страдать, а то я себя обделенным чуствую.
p.s. минус не мой был, если что :)
Конечно, журналирование — это один из тех кейсов, где триггеры самое оно. Но переносить на них бизнес логику…
Как по мне CQRS + event sourcing поудобнее триггеров будет для задач журналирования. Но опять же есть случае где этот подход не катит. Универсальных решений и абсолютного зла не бывает. Просто если можно обойтись без процедур (а обычно можно) — лучше обойтись без процедур. Это вопрос подходов, выбранных методологий разработки и т.д.
Для процедурок есть свои ниши, связанные с разграничением доступа к данным и бизнес логике. Там другие подходы тоже работают но не так хорошо.
Для процедурок есть свои ниши, связанные с разграничением доступа к данным и бизнес логике. Там другие подходы тоже работают но не так хорошо.
о, теперь я знаю, как это называется. Делал такой велосипед при реализации аналога 1С регистров. Но есть свои ограничения, для хайлоада не катит.
для хайлоада не катит.
Катит. Единственный случай, когда CQRS не подходит (может и не единственный, но я знаю только об этом), это если наша система должна читать и изменить данные атомарно (пимер — стэк и pop, который за одну операцию считывает элемент в конце массива и удаляет его из оного, если мы разделим на чтение + запись то при конкурентных запросах будет плохо, так как один из запросов на чтение может вернуть не то) то да, CQRS не подходит. Но это не такой уж частый кейс и уж никак он не связан с хайлоадом. А event-sourcing — зависит от реализации. Можно писать лог изменений сначала в память а потом уже в базу, можно еще придумать прикольных штук.
Ну а мне пост понравился. Я не адепт всего нового, и давно не тяну первые попавшиеся вещи в проекты, но познакомиться с новыми подходами, и хотя бы просто оценить их жизнеспособность, применительно к своим проектам, никогда не помешает. Вот только бы агрессивности поменьше, а то иногда обидно, когда git-flow тебе не подходит из-за требований заказчика, и тебя из-за этого называют мамонтом. :(
Отличные комменты)))
Вот что я бы сюда ещё реально добавил, постоянно глядя на жуткий разнородный код генерации HTML в MediaWiki: вы всё ещё выводите HTML print'ами? А может ?> <?php вставками? А может сборкой в строку или специально придуманными хелпер методами? Записывайте себе -30 очков… :)
А то фиг с ними, со сценариями сборки, но когда я вижу помесь PHP и HTML — вот уж где мамонты так мамонты...)) а оно живо… вон, вся медиавики так написана.
Вот что я бы сюда ещё реально добавил, постоянно глядя на жуткий разнородный код генерации HTML в MediaWiki: вы всё ещё выводите HTML print'ами? А может ?> <?php вставками? А может сборкой в строку или специально придуманными хелпер методами? Записывайте себе -30 очков… :)
А то фиг с ними, со сценариями сборки, но когда я вижу помесь PHP и HTML — вот уж где мамонты так мамонты...)) а оно живо… вон, вся медиавики так написана.
"?><?php" как раз нормальная практика, если использовать данный функционал разумно. По «разумностью» подразумевается использование php условий, циклов и инклудов и ничего более.
Разумнее использовать шаблонизаторы. Чтобы просто не иметь возможности написать SQL-запрос в шаблоне. Имхо.
Sign up to leave a comment.
Не мамонт ли Вы? (пятничный тест; который ложь, да в ней намек)