Де-факто, тестирование, и гибкая разработка, нужна лишь программистам/компаниям, играющим по взрослому.
Теперь зададим себе вопрос: а что такое тест? По-сути, это некоторый код, который запускает другой код (в цикле, с разными параметрами конфигураций и т. д). Ловит исключения, регистрирует их.
Так вот у меня вопрос: много людей, которые не делают этого? Т. е. не пишут стартер для классов?
Из плюсов больше всего бросилось
1. Качество кода. Код действительно красивый. Что говорится, ООП не для ООП, а для простоты.
2. Часто примеры публикуют. Документация нормальная. Интеграция сторонних библиотек.
3. Широкая сфера применения: лучше всего смотреть на проекты. Они на сайте даются: например, файловый архив (а-ля рапида), блоги, магазины.
Ну и среда разработки Adept IDE(под эклипс и как отдельное приложение).
Всегда использовал свои разработки.
Есть ряд причин этому:
1. Своя документация
2. Возможность безболезненно добавлять функционал и не бояться апдейтов
3. Разные сборки фреймворков(сервисный, под CMF)
4. Можно реализовать то, чего еще нет (архитектура драйвер/адаптер/исполнитель)
5. Набираешься опыта, пока пишешь…
Из минусов:
1. Изобретение велосипеда, в своем роде
2. Нужно поддерживать пользователей.
Из тех, которые смотрел, больше всего понравился Adept.
Господа, вы, конечно, извините. Но такие решения — это ппц. Вот почему:
1. Врядли среди аудитории найдется компания, которая «шлепает» хотябы по 2 web-проекта в день.
2. Если найдется — сисадмины давно придумали вещи веселее текущей.
3. Отсутствие «конфигурируемости» подобного решения — явный косяк. А что, если проект на перле (в добавляемой конфигурации не увидел ничего про cgi-bin/cgi)? А что, если не нужна БД? Где интерактивность? :)
Эти операции делаются ручками за 2 минуты. Не разбираешься в конфигах — не лезь. (разобраться-то, 2 минуты).
Еслиб написали проект реализации всех этих вещей через web-интерфейс (а-ля ISP) — думаю, люди были бы более благодарны. Скрипт не поможет, если не влезть в него руками :)
Увы и ах, но пришлось отказаться от подобного наименования, ибо в PHP оно неэффективно.
Нередко встречаются случаи, когда изначально не знаешь, какой тип у тебя будет храниться в текущей переменной — это факт.
В качестве примера можно привести метод, принимающий переменную $array. Дальше он смотрит — если это массив — возвращает его и делов. Если строка — return explode(', ', $array);
Вот тут непонятки страшнее преимуществ, которые достигаются подобным именованием.
Домен — это домен, логин — это логин, отображаемое имя — это другое, email-третье.
В каждом мало мальски серьезном проекте используется куча параметров у пользователя.
Если говорить о том, как делаю я:
1. domain.site.ru — это алиас site.ru/domain. Т.е. человек всегда может выбрать что ему удобнее: домен или папка.
2. логин — может быть абсолютно любой незанятый. Он на то и создан, чтобы «войти», «авторизоваться».
3. отображаемое имя. Оно же — никнейм. Может менять его сколько желает.
4. email стандартен — используется для восстановления пароля.
Для авторизации может использоваться каждый из 4-х параметров — мне разницы нет. Все-равно в сессии храню его целочисленный идентификатор.
phpdude, я за PHP, если что. А то выглядит как «учись готовить»: D
Просто вот для таких людей пишешь как заставить PHP работать быстрее, а они говорят, что экономия на спичках (это я про свой первый хабрапост «Работа со строками»): D
Пля, отправил рано. ((
Суть в том, что НИ ОДИН ЧЕЛОВЕК из обсуждавших сию новость ни на коднете ни на лоре не согласился с результатами.
Так что не будем разводить холливар. А то достало уже показывать «небыдлокодерам» почему PHP не только отстоял свое право на жизнь у ASP.NET и JAVA в сфере Web, но и развивается нехило )))
Уважаемый, я вас огорчу: на любом языке можно реализовать любой функционал (исключая клиентские вещи). Даже ось можно написать на PHP. Не суть важно ;)
Другое дело — смешивание 2-х и более языков в приложении. Кому оно нужно? Любой PHP-разработчик встречает задачи, который в нативном PHP не предусмотрены. И решает эти задачи.
Любой разработчик встречает задачи, которые в его нативном языке не предусмотрены. А демон на Java — это не меньший изврат, кстати ;)
ЗЫ: есть куча примеров Online-игр написанных на PHP. Все быдлокодеры?: D: D: D
Послушайте следующую мысль: она будет полезна.
1. Я не говорил ни о каком другом языке: в топике рассмотрен только PHP и только аспект «строка в PHP». Так что говорить о других языках — это как «Я тебе про Фому, ты мне про Ерему».
2. Получение (не обработку данных) в PHP из БД оптимизировать нельзя — это нативный функционал. Лезьте в сошники и правьте — тогда поговорим. :)
Не бывает оптимизированных скриптов, который оптимизированы только в одну сторону. Оптимизация ПО — процесс, затрагивающий каждый файл, каждую строку кода :)
Давайте смотреть реальности в глаза. Если какой-то функционал (который удобнее) реализован в Перле — его можно реализовать на любом языке, раз мы не говорим о быстродействии (в т.ч. и PHP сюда включим).
Поэтому говорить, что какой-то язык справляется с чем-то лучше, по крайней мере, некорректно. То, что где-то идет «в комплекте» библиотека-враппер — ни о чем не говорит. Напишите его и не морочьте людям голову — понять могут неправильно.
> Я сказал «быстрее»? Я сказал «лучше»!… Будьте так добры, читать внимательнее
Вы сами прочтите внимательно. «… быть быстрее/справляться лучше нативного...»
ЗЫ: Что за глупость «слизаны у PERL»? До перл-совместимых были BRE (UNIX) и ERE(POSIX). Многие вещи PCRE унаследовал от POSIX, который был расширением UNIX. Получается, что PERL их слизал и расширил/изменил?: D
Давайте еще скажем, что PHP слизал синтаксис у С/С++? За сим откланиваюсь. Смысла спорить нет.
«Сутью многопоточности является квазимногозадачность на уровне одного исполняемого процесса, то есть все потоки выполняются в адресном пространстве процесса.». Вика.
Теперь зададим себе вопрос: а что такое тест? По-сути, это некоторый код, который запускает другой код (в цикле, с разными параметрами конфигураций и т. д). Ловит исключения, регистрирует их.
Так вот у меня вопрос: много людей, которые не делают этого? Т. е. не пишут стартер для классов?
Из плюсов больше всего бросилось
1. Качество кода. Код действительно красивый. Что говорится, ООП не для ООП, а для простоты.
2. Часто примеры публикуют. Документация нормальная. Интеграция сторонних библиотек.
3. Широкая сфера применения: лучше всего смотреть на проекты. Они на сайте даются: например, файловый архив (а-ля рапида), блоги, магазины.
Ну и среда разработки Adept IDE(под эклипс и как отдельное приложение).
Есть ряд причин этому:
1. Своя документация
2. Возможность безболезненно добавлять функционал и не бояться апдейтов
3. Разные сборки фреймворков(сервисный, под CMF)
4. Можно реализовать то, чего еще нет (архитектура драйвер/адаптер/исполнитель)
5. Набираешься опыта, пока пишешь…
Из минусов:
1. Изобретение велосипеда, в своем роде
2. Нужно поддерживать пользователей.
Из тех, которые смотрел, больше всего понравился Adept.
1. Врядли среди аудитории найдется компания, которая «шлепает» хотябы по 2 web-проекта в день.
2. Если найдется — сисадмины давно придумали вещи веселее текущей.
3. Отсутствие «конфигурируемости» подобного решения — явный косяк. А что, если проект на перле (в добавляемой конфигурации не увидел ничего про cgi-bin/cgi)? А что, если не нужна БД? Где интерактивность? :)
Эти операции делаются ручками за 2 минуты. Не разбираешься в конфигах — не лезь. (разобраться-то, 2 минуты).
Еслиб написали проект реализации всех этих вещей через web-интерфейс (а-ля ISP) — думаю, люди были бы более благодарны. Скрипт не поможет, если не влезть в него руками :)
А то, что господам из Майкрософт эта идея понравилась только сейчас — это их проблемы, имхо :)
Нередко встречаются случаи, когда изначально не знаешь, какой тип у тебя будет храниться в текущей переменной — это факт.
В качестве примера можно привести метод, принимающий переменную $array. Дальше он смотрит — если это массив — возвращает его и делов. Если строка — return explode(', ', $array);
Вот тут непонятки страшнее преимуществ, которые достигаются подобным именованием.
ЗЫ: это простейший случай ;)
crypt, md5, sha1, mhash, etc.
А вот тут — совсем уж предел игр разума.
Вообщем — за обработку текста в худшую сторону — жирный кол. Ничего личного.
Домен — это домен, логин — это логин, отображаемое имя — это другое, email-третье.
В каждом мало мальски серьезном проекте используется куча параметров у пользователя.
Если говорить о том, как делаю я:
1. domain.site.ru — это алиас site.ru/domain. Т.е. человек всегда может выбрать что ему удобнее: домен или папка.
2. логин — может быть абсолютно любой незанятый. Он на то и создан, чтобы «войти», «авторизоваться».
3. отображаемое имя. Оно же — никнейм. Может менять его сколько желает.
4. email стандартен — используется для восстановления пароля.
Для авторизации может использоваться каждый из 4-х параметров — мне разницы нет. Все-равно в сессии храню его целочисленный идентификатор.
Просто вот для таких людей пишешь как заставить PHP работать быстрее, а они говорят, что экономия на спичках (это я про свой первый хабрапост «Работа со строками»): D
Суть в том, что НИ ОДИН ЧЕЛОВЕК из обсуждавших сию новость ни на коднете ни на лоре не согласился с результатами.
Так что не будем разводить холливар. А то достало уже показывать «небыдлокодерам» почему PHP не только отстоял свое право на жизнь у ASP.NET и JAVA в сфере Web, но и развивается нехило )))
Другое дело — смешивание 2-х и более языков в приложении. Кому оно нужно? Любой PHP-разработчик встречает задачи, который в нативном PHP не предусмотрены. И решает эти задачи.
Любой разработчик встречает задачи, которые в его нативном языке не предусмотрены. А демон на Java — это не меньший изврат, кстати ;)
ЗЫ: есть куча примеров Online-игр написанных на PHP. Все быдлокодеры?: D: D: D
1. Я не говорил ни о каком другом языке: в топике рассмотрен только PHP и только аспект «строка в PHP». Так что говорить о других языках — это как «Я тебе про Фому, ты мне про Ерему».
2. Получение (не обработку данных) в PHP из БД оптимизировать нельзя — это нативный функционал. Лезьте в сошники и правьте — тогда поговорим. :)
Не бывает оптимизированных скриптов, который оптимизированы только в одну сторону. Оптимизация ПО — процесс, затрагивающий каждый файл, каждую строку кода :)
То, о чем и говорили — демонизация и раздача заданий рулит ;)
Поэтому говорить, что какой-то язык справляется с чем-то лучше, по крайней мере, некорректно. То, что где-то идет «в комплекте» библиотека-враппер — ни о чем не говорит. Напишите его и не морочьте людям голову — понять могут неправильно.
> Я сказал «быстрее»? Я сказал «лучше»!… Будьте так добры, читать внимательнее
Вы сами прочтите внимательно. «… быть быстрее/справляться лучше нативного...»
ЗЫ: Что за глупость «слизаны у PERL»? До перл-совместимых были BRE (UNIX) и ERE(POSIX). Многие вещи PCRE унаследовал от POSIX, который был расширением UNIX. Получается, что PERL их слизал и расширил/изменил?: D
Давайте еще скажем, что PHP слизал синтаксис у С/С++? За сим откланиваюсь. Смысла спорить нет.
«Сутью многопоточности является квазимногозадачность на уровне одного исполняемого процесса, то есть все потоки выполняются в адресном пространстве процесса.». Вика.
Ооочень напоминает бред Жабистов о том, что Java работает быстрее С/C++. Как скриптовый язык может быть быстрее/справляться лучше нативного языка?