Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Linux использует Git где-то с 2005 года, собственно, Линус для Linux и создал Git (http://ru.wikipedia.org/wiki/Git). GitHub != Git.
Там и сказано о недавнем переносе Linux на GitHub, а не на Git. Так же там говорится о том, что php переходит на Git. По мне так, все правильно описано.
Если бы не упоминали GitHubLinux, — новость была бы корректной. А так — смешаны в одно разные новости совершенно.
Ладно Вам. Там Linux ради примера приведен. Без вступительного текста новость оказалась бы жиденькой =)
Хорошо, убрал это вообще, чтобы не раздражало.
спасибо.
А теперь нам думать, что же там было… Можно было бы, например, просто зачеркнуть.
Вам не угодишь. :)
Ну серьезно, одно дело орфографическую ошибку исправить «прозрачно», другое дело какой-то тезис, который в половине комментов обсуждается удалить.
Поддержу VolCh. Сейчас получается так, что akzhan заметил что-то касательно первоначального текста. Видимо что-то резонное, раз в итоге текст был изменен. Но его камент для тех, кто видел только вторую версию топика, кажется каким-то левым и он за это ловит минусы.
Да, говорится о Git и в качестве подтверждения слов «Git быстро утверждается в качестве всеобщего стандарта» приводится в пример репозиторий Linux, что на самом деле выглядит забавно. Так что вроде как описано всё правильно, но… не очень.
На днях за переход на Git проголосовали участники группы php.internals.
Приветствую!
Голосовать могли не группа «internals» (это вообще не группа, а список рассылки, на который может подписаться кто угодно), а все у кого есть SVN аккаунт к php-src, документации и пр.
Результаты голосования можно увидеть здесь. А здесь сам RFC по данному вопросу.
На Github уже перенесли зеркало исходников PHP, хотя полностью переходить на Github пока не собираются, вся работа будет на git.php.net.
Использовать гитхаб вообще пока никто не собирается.
Указанное вами зеркало — зеркало с SVN, существующее с сентября 2008 года, когда о переходе на DVCS тоже никто не думал.
Спасибо за внимание, надеюсь кому-то пригодятся эти подробности.
Вот редко минусую комменты, но… Вам он жить мешает? Мне, вот, помогает. Вам жалко?
>>PHP весьма удобен для написания небольших динамических сайтов (домашних страничек, например), но категорически не является подходящим инструментом для создания чего-то большего
автор когда писал эту статью наверно и не подозревал что где-то на другом конце мира на этом ПеХеПе пишется самый популярна и один из самых высоконагруженых соц. сетей))
автор когда писал эту статью наверно и не подозревал что где-то на другом конце мира на этом ПеХеПе пишется самый популярна и один из самых высоконагруженых соц. сетей))
Сначала так и было, PHP был создан для легкой обработки форм что-то типа генерации отчетов, примерно по такой схеме:
1. прочитали данные из переменных, в которые они автоматически попали
2. обработка данных, через файлы и запросы из SQL
3. красивый вывод прямо на той же странице
И всё это в одном файле.
— Но времена меняются, на пхп пишутся соцсети, фреймворки и цмс, и разработчики уже вынуждены добавлять фичи типа неймспейсов и нативной поддержки юникода :)
1. прочитали данные из переменных, в которые они автоматически попали
2. обработка данных, через файлы и запросы из SQL
3. красивый вывод прямо на той же странице
И всё это в одном файле.
— Но времена меняются, на пхп пишутся соцсети, фреймворки и цмс, и разработчики уже вынуждены добавлять фичи типа неймспейсов и нативной поддержки юникода :)
Про недостатки в курсе, но лично для меня их перевешивают достоинства. Прототип я могу набросать на рельсах, но для продакшена выберу php (если вообще будет возможность выбирать). Экономически мне так выгоднее.
Простота развёртывания приложения на «голом» сервере. Масса движков и фреймворков на любой вкус под разные задачи, как коммерческих, так и открытых (противопоставление не совсем корректное, но пусть) с большими сообществами, в том числе русскоговорящих. Масса материалов в сети (пускай частично устаревших, а отчасти даже вредных), в том числе на русском языке. Большое количество программистов, владеющих языком (то есть способных «подхватить» проект) и, как следствие большого предложения — их низкая стоимость. Плюс пресловутый низкий порог входа. Ну и спрос на php-программистов на фриланс-ресурсах, да и «по знакомым» выше.
Для меня определяющий первый фактор, пускай он и субъективен. Склепать прототип мне быстрее на рельсах (также джангу пробовал для этих целей, но не понравилось). Писать «релиз» почти без разницы на чём из упомянутых. Но разворачивать и поддерживать как приложение, так и среду выполнения, мне, как непрофессиональному администратору, проще на PHP: утрируя, один раз apt-get install, периодически apt-get update && apt-get upgrade и rsync по коммиту.
Для меня определяющий первый фактор, пускай он и субъективен. Склепать прототип мне быстрее на рельсах (также джангу пробовал для этих целей, но не понравилось). Писать «релиз» почти без разницы на чём из упомянутых. Но разворачивать и поддерживать как приложение, так и среду выполнения, мне, как непрофессиональному администратору, проще на PHP: утрируя, один раз apt-get install, периодически apt-get update && apt-get upgrade и rsync по коммиту.
В том-то и дело, что знаний требуется явно больше и не в любой среде, а создать среду с нуля. А главное, нормального источника этих знаний, пускай и объёмных, я нагуглить не смог в своё время — сведения большей частью отрывочные, предполагающие, видимо, какое-то «тайное знание», например расписано как установить и настроить продакшен среду, но не расписано как её обновлять, если установка производится не штатными средствами ОС (тем же апт-гет), а, скажем, сборкой из сорцов. Или, скажем, как тот же собранный из сорцов nginx+passenger добавить в «автозагрузку», чтоб после рестарта сервера не нужно было лезть в консоль и запускать их ручками. Наверное, гугля каждый возникающий вопрос с этим и можно разобраться, но у меня вопросов возникает сразу много и гугление с фильтрацией устаревшей инфы отнимает очень много времени, а главное проект стоит, основная задача не решается.
От темы топика мы давно отклонились :)
Так в том-то и дело, что не заставляет. И это очень удобная практика для проектов, где максимум есть один сервер-сайд разработчик и он же вынужденно администратор (а не он же клиент-сайд, он же верстальщик, а то ещё и дизайнер и юзабилист), где некому сказать «сделай так, чтобы вот этот скрипт работал всегда и запускался в штатный режим до веб-сервера» или, хотя бы «я тут погуглил и сделал это так, проверь, всё правильно, это *-way? если всё ок — пускай в продакшен». Грубо говоря, программиста под LAMP интересует только AMP (и, по сути, даже мало интересует L там, B или W), и то только в общих чертах — глянуть как реализована та или иная функция в PHP в чём, например отличие *_connect и _pconnect (благо синтаксис C и PHP схож и разобраться в исходниках PHP можно без специального изучения C), логи апача (хотя предпочитаю nginx) и план запроса в мускуле — всё остальное сделали разработчики языка/дистра/пакетов. Разбираться в rc.d или других процедурах запуска это спускаться на минимум два уровня абстракции ниже основного необходимого для решения задачи. Можно при необходимости, но она возникает крайне редко и, имхо, для проектов такого масщтаба, где «выделенный» админ, а не «эникейщик» уже тоже необходимость и первая необходимость нужна больше, чтоб говорить с ним на одном языке, а не что-то самому делать. Называть это недостатком языка как-то язык не поворачивается, сорри за каламбур. А день разбирательства стоит заказчику/работодателю как два-четыре месяца работы среднего VDS. Железо дешево и до определенных масштабов проще тупо покупать дополнительное.
А что до качества кода — мой код, наверное, одинаково некачественный, что на PHP, что на Ruby, что на Python (если не учитывать *-way). И ещё более некачественный на Java, C# и С++ (там даже тестов нет, правда и код типаhello world «бложика» — CRUD). И от знания процедур автоматического запуска его качество вряд ли изменится. А с PHP я использую не одну парадигму. И даже функциональную начал использовать раньше, чем появилась её более-менее полноценная поддержка. Механизм callback/callable в PHP существует, если не с рождения, то с PHP3 точно (на который и я пришёл с десктопов и С++, где указатели на функции сущности первого класса), очень костыльный (но иной раз более гибкий), но существует. ООП появился в PHP4 (в 3 его очень не хватало), стал приличным в PHP5. Основные недостатки PHP для меня сейчас:
— отсутствие нативное поддержки юникода (жду в 6)
— отсутствие type hinting (не путать со статической типизацией) для примитивных типов данных
— отсутствие именованных параметров функций/методов при вызове
— несогласованность именования сигнатур функций/методов в библиотеках (да и вообще отсутствие единых naming convenentions и coding style)
— временами очень громоздкий синтаксис (в 5.4 жду нормального дереференса и краткого объявления массивов, плюс именованные параметры)
— хочется конструкций аналогичной yield и блокам в Ruby :)
P.S. А нейсмпейсы с 2006 года появились и лично мною активно используются, даже со своим личным vendor-префиксом :)
Так в том-то и дело, что не заставляет. И это очень удобная практика для проектов, где максимум есть один сервер-сайд разработчик и он же вынужденно администратор (а не он же клиент-сайд, он же верстальщик, а то ещё и дизайнер и юзабилист), где некому сказать «сделай так, чтобы вот этот скрипт работал всегда и запускался в штатный режим до веб-сервера» или, хотя бы «я тут погуглил и сделал это так, проверь, всё правильно, это *-way? если всё ок — пускай в продакшен». Грубо говоря, программиста под LAMP интересует только AMP (и, по сути, даже мало интересует L там, B или W), и то только в общих чертах — глянуть как реализована та или иная функция в PHP в чём, например отличие *_connect и _pconnect (благо синтаксис C и PHP схож и разобраться в исходниках PHP можно без специального изучения C), логи апача (хотя предпочитаю nginx) и план запроса в мускуле — всё остальное сделали разработчики языка/дистра/пакетов. Разбираться в rc.d или других процедурах запуска это спускаться на минимум два уровня абстракции ниже основного необходимого для решения задачи. Можно при необходимости, но она возникает крайне редко и, имхо, для проектов такого масщтаба, где «выделенный» админ, а не «эникейщик» уже тоже необходимость и первая необходимость нужна больше, чтоб говорить с ним на одном языке, а не что-то самому делать. Называть это недостатком языка как-то язык не поворачивается, сорри за каламбур. А день разбирательства стоит заказчику/работодателю как два-четыре месяца работы среднего VDS. Железо дешево и до определенных масштабов проще тупо покупать дополнительное.
А что до качества кода — мой код, наверное, одинаково некачественный, что на PHP, что на Ruby, что на Python (если не учитывать *-way). И ещё более некачественный на Java, C# и С++ (там даже тестов нет, правда и код типа
— отсутствие нативное поддержки юникода (жду в 6)
— отсутствие type hinting (не путать со статической типизацией) для примитивных типов данных
— отсутствие именованных параметров функций/методов при вызове
— несогласованность именования сигнатур функций/методов в библиотеках (да и вообще отсутствие единых naming convenentions и coding style)
— временами очень громоздкий синтаксис (в 5.4 жду нормального дереференса и краткого объявления массивов, плюс именованные параметры)
— хочется конструкций аналогичной yield и блокам в Ruby :)
P.S. А нейсмпейсы с 2006 года появились и лично мною активно используются, даже со своим личным vendor-префиксом :)
Да вроде вас я понял. Вы предлагаете мне изучить администрирование Линукс вообще и развёртывание приложений на Рельсах/Джанго в частности, с тем чтобы писать на «великолепных языках» (Python, судя по профилю, имеете в виду? :) ). Ну не смог я найти за день нормальной хаутушки как, оставаясь on edge (условно — последние минорные апдейты мажорной стабильной версии) со средой выполнения, админить на начальном уровне (без тюнинга под хайлоад и т. п.) стэйджинг/продакшен систему в debian-way. Для PHP знаю репозитории (+PEAR, +PECL, но это редко), для Python/Ruby не знаю, плюс заморочки с virtualenv/RMP (если в написании не ошибся, но, наверное, понятно). За день (для каждого фреймворка) не смог найти — не могу даже спрогнозировать сколько времени самостоятельное изучение от самого низкого уровня (уровня ОС) займёт, а задачи стоят и показать заказчику нечего. Лучше я буду решать задачи на языке с недостатками (не такими уж страшными, даже без Юникода — по сути, «сахара» не хватает, а не возможностей), но имея возможность прогнозировать сроки, чем неизвестное мне количество времени разбираться с администрированием, а не заниматься программированием.
А может не Линукс, а GAE? :) Его я тоже использовал для прототипирования с Джангой (как сейчас Рельсы с heroku). Один раз даже пришлось из Джанги вытаскивать стили админки и прикручивать их к Symfony, настолько стиль заказчику понравился. Но это прототипы (про сложности джанги с nosql, даже с django-nonrel, забудем) на «бесплатных» хостингах, готовых к развёртыванию приложения буквально в одну команду. Как так настроить VPS и среду разработки я не знаю и нагулить не смог (впрочем повторяюсь).
А может не Линукс, а GAE? :) Его я тоже использовал для прототипирования с Джангой (как сейчас Рельсы с heroku). Один раз даже пришлось из Джанги вытаскивать стили админки и прикручивать их к Symfony, настолько стиль заказчику понравился. Но это прототипы (про сложности джанги с nosql, даже с django-nonrel, забудем) на «бесплатных» хостингах, готовых к развёртыванию приложения буквально в одну команду. Как так настроить VPS и среду разработки я не знаю и нагулить не смог (впрочем повторяюсь).
Я сам считаю его хорошим языком и намного более целостным и приятным, чем PHP (Ruby слишком, имхо, сладкий — стараюсь «сладости» не использовать). Но как программист — как нубоадмин считаю его более сложным в поддержке.
Openvz/kvm я юзаю как root «гостевой» ОС: echo '...' >> /etc/apt/sources.list && apt-get update && apt-get install php5,… и своего мнения не имею о них, кроме как kvm субъективно меньше тормозит при нагрузочном тестировании и своп, кажется, в openvz невозможен по определению. Этот уровень абстракции намного ниже тех, с которым привык работать в этом веке :)
Вам тоже удачи и спасибо за интересный диалог.
Openvz/kvm я юзаю как root «гостевой» ОС: echo '...' >> /etc/apt/sources.list && apt-get update && apt-get install php5,… и своего мнения не имею о них, кроме как kvm субъективно меньше тормозит при нагрузочном тестировании и своп, кажется, в openvz невозможен по определению. Этот уровень абстракции намного ниже тех, с которым привык работать в этом веке :)
Вам тоже удачи и спасибо за интересный диалог.
И с праздником :)
Главное, чтобы не наоборот!
А чем subversion не угодил?
На hginit.com дано неплохое краткое объяснение, например.
Мне лично пофиг Git или SVN, лижбы PHP развивался.
ха, те кто остались на svn уже просто пробовали мигрировать свои проекты под git и решили отложить это до следующей пятилетки.
Как-то за Меркуриал обидно.
Мигрировал на него свои проекты с SVN — жизнь стала легкой и заиграла красками! :)
Мигрировал на него свои проекты с SVN — жизнь стала легкой и заиграла красками! :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PHP переходит на Git