Ох… да сколько же можно… зачем столько платежных систем?
Вы бы хотя бы написали чем отличаетесь от всех остальных? В чем ваши преимущества? Как насчет обмена с другими ПС? Снова все через одно место + дикие проценты? и т.д. и т.п.
> Visual Studio отражает все изменения в диаграмме классов, то не знаю, есть ли для PHP подобные инструменты (но, думаю, где-то должны быть)
Если вы про дерево классов и методов — то да, а вот если про UML — то нет.
> А менять модель, которая обновляет код — вот этого я не хотел бы в своем проекте.
На самом деле очень удобно — добавили классы/интерфейсы/методы их каркасы будут автоматически сгенерированы — останется только наполнить их кодом.
> К слову — а так ли нужны эти диаграммы, если все есть в коде?
Более наглядно и позволяют охватить весь проект целиком (мелкие детали при необходимости можно скрыть). Теоретически можно изменив модель поменять и код (т.к. тела методов можно хранить в диаграмме), но на практике есть трудности.
Это все специфично именно для PHP, для некоторых других языков (тот же Java) проблем намного меньше.
Предположим, решили грамотно и правильно спроектировать архитектуру используя UML. Набросали каркас. Встает первая проблема — генерация кода, большинство инструментов это позволяют, НО очень малое их число позволяют изменить формат** вывода (т.е. оформить код в соответствии с нужными требованиями). Досадно. Придется исправлять вручную или оставить как есть.
Реализовали каркас, добавили несколько методов (в коде) и классов/интерфейсов. Вторая проблема — а как обновить модель? Часть инструментов это позволяет, НО при этом выясняется что часть информации из модели теряется (а мы старались, делали)… тот же EA*, например, полностью проигнорирует типы аргументов методов (проблеме несколько лет — исправлять её похоже никто не собирается) — придется их восстанавливать. Можно конечно изменять вручную, но это не оправдано и не думаю что кто-то будет это делать для больших проектов (со временем что нибудь забудем и получим расхождение модели и кода).
Попробуем с другой стороны — изменяем модель и пытаемся обновить код — здесь тоже не все гладко… Для EA* например придется вручную указывать соответствие методов в модели и в коде, для больших классов надоест очень быстро.
А вот теперь главный вопрос — оправданы ли все эти затраты? По-моему — нет.
* — Enterprise Architect — самый дешевый моделер с возможностью настройки настройки формата файлов (вроде простая функция, но её нет во многих инструментах)
** — это тоже придется сделать вручную, хотя и один раз (но зато он может занять много времени).
P.S. В ближайшее время собираюсь попробовать Eclipse + Papyrus + Acceleo может и получится что нибудь приемлемое для практического использования.
> но за, скажем, python или ruby платят, как правило, больше
Это естественно, т.к. разработчиков намного меньше (на фрилансе вообще плохо). Но со временем их станет больше, цены уравняются, и количество быдло кода на python или ruby тоже станет больше (как будто что-то может помешать его написанию).
Об архитектуре сложно думать т.к. инструментов которые позволяют *полноценно* работать с PHP просто не существует. В итоге чем больше проект, тем больше времени тратиться на синхронизацию моделей (имею в виду UML) и кода…
> 2. Компании и контракты — как и задачи привязаны к проектам;
Этого нет в стандартном варианте. Как и «Отчет за месяц». Хотя может у меня версия старая? (одна из предшествующих 1.0.0 ревизий)
Или это какие-то дополнения?
> 6. Учет бюджета, выставление счетов, проект типа продажа
Этого тоже нет из коробки.
> 8. Контроль прав доступа — каждой группе пользователей назначены свои права;
Не хватает приватных задач. (т.е. если проект общедоступный все видят любые задачи). Ждем 1.1.0.
> 9. Стоимость — open source.
Развиваться вроде медленнее стал
> Все равно assertion как-то обрабатывать надо, чтобы не изобретать велосипед используем готовую модель. Если где-то assertion не пройдет получаем исключение, а с ним и trace. Тут кому как больше нравится.
Единственная обработка которая нужная при срабатывании асерта — это исправление ошибки (на дев сервере, на рабочем он все равно никогда не сработает).
> если у вас задумана логика, что если строки локализации нет, то вывести то что есть, так и напишите это в коде:
Так нельзя делать. Обнаружить пропущенную строку при таком подходе невозможно. Это как раз тот случай когда больше всего подходят E_NOTICE (или E_USER_NOTICE).
> представьте себе ситуацию, если вы не проверяете наличие ключа в массиве, этот не существующий элемент массива будет преобразован в null, пустую строку, 0, или false.
Это больше относится к стилю программирования, чем к обработке ошибок… Все нотисы оседают в логи (нотисы я считаю ошибками и при нормальной работе их быть не может) достаточно посмотреть их чтобы обнаружить пропущенную строку (индекс и т.д.). Ну, а на дев сервере нотисы сразу выводятся вместе с трассой (спасибо xdebug) и исправляются при обнаружении.
Зачем здесь исключение?
+ Есть еще E_DEPRECATED/E_USER_DEPRECATED на который вообще нельзя бросать исключение, т.к. код полностью рабочий хотя и устаревший.
+ Часть стороннего кода (в большом проекте он в большинстве случаев будет) может не считать E_NOTICE ошибкой, в вашем случае потребуются костыли чтобы заставить его работать.
> Преобразуйте все ошибки утверждений (assertion fail) и не фатальные ошибки в исключения
> Правильно. Я предлагаю бросать исключения в случае не прохождения утверждения (assertion fail)
Асерты работают только в режиме разработки и служат исключительно для тестирования и отладки кода, т.о.
1) Они НЕ предназначены для обработки ошибок и не могут возникнуть на продакш сервере
2) Переводить их в исключения — нелогично, т.к. это сильно усложнит обработку ошибок + это пустая трата времени (см. п.1)
На хабре, помню, асерты обсуждались очень подробно, но что-то не смог найти :(.
Касательно «не фатальные ошибки» — тоже не согласен. Вы забываете, что не фатальная ошибка (предупреждение, нотис и д.р.), в отличие от исключения НЕ приводит к прерываю работы, т.е. она позволит продолжить работу скрипта и вывести пользователю какие либо данные. Исключение же потребует реализации логики для вывода ошибки и вывода чего-то пользователю. Ну а реагировать на нотис исключением вообще глупо (скажем, не найдена строка локализации — думаете показать пользователю ошибку что её нет лучше, чем просто вывести страницу без неё?)
Добавлю еще один пункт:
X) ВСЕГДА указывайте какие исключения выбрасывает метод (@throws) — в будущем сильно сэкономите время себе и поможете другим разработчикам.
Без последнего пункта весь ваш код со временем выродится — все try блоки будет ловить только базовое исключение, т.к. разработчикам будет лень рыться в чужом коде и искать какие исключения он выбрасывает.
Спасибо. Это я видел и даже пытался поставить (под win), но вот как его использовать — непонятно.
P.S. Хотел PHP проект прогнать, но как выяснилось уже после установки, похоже, нужен проект под maven. Просто так — без maven (только ради sonar-a не хочется его использовать), его нельзя запустить?
vacuum он точно не делает — пару дней назад наблюдал как он после полной очистки истории заново создавал places.sqlite точно такого же размера… Вручную запущенный vacuum уменьшил файл в ~50 раз.
Безусловно, хорошая новость, даже не смотря на высокий процент.
Непонятно только как это выглядит с правовой стороны — например, не придет ли потом налоговая за своим процентом? (беглый просмотр документации ничего не дал, если кто-то поделится полезной ссылкой буду благодарен).
> IBResource по соглашению с разработчиком не имеет права продажи только локализации. Часть клиентов, купивших у Invision Power, очень жалели об этом, покупая «еще одну» лицензию за полную сумму.
Значит я ошибался :(. Вроде где-то видел что можно отдельно купить… посмотрел в клиентском разделе для форума действительно отдельно не продается (для остальных есть).
> Но при этом доработки за вас уже внесены, что означает отсутствие необходимости ползать по багтрекерам и форумам в поиске решений.
Не все — ни IPS ни IBR (через тиккет можно) не хотят исправлять вывод русских дат в Win системах, хотя в ранних версиях это было.
IBR у меня не ассоциируется с нормальной компанией, например из-за этого — ibresource.ru/products/ipboard/eula/ — сейчас там вместо лицензии выводится страница сайта IPS, когда покупал сам там вообще было «404 Not Found»… (в саппорт об этой и еще нескольких ошибках сообщал).
Каждый сам выбирает что ему важнее
* нормальный доступ к бесплатным ресурсам и некоторые баги (которые можно поправить)
или
* небольшие доработки, получение бесплатных модификаций через достаточно медленную тех. поддержку и отсутствие бесплатных cервисов (кроме генератора скинов)
1) Покупать есть смысл только третью версию (скоро выйдет 3.1.0), покупать лучше напрямую у IPS, у IBR — только локализацию (т.к. если купить лицензию не будет доступа к бесплатным ресурсам, которых у IPS достаточно много… модули можно получить через тех поддержку, но отвечает она по несколько дней)
3) Также есть бесплатные для клиентов: IP.Tracker (багтрек, используют сами), IP.Shoutbox (чат), и т.д. (можно найти на их сайте)
4) Очень просто разрабатывать модификации (мелкие изменения функционала; в большинстве случаев можно обойтись без модификации кода форума) и приложения (типа IP.Gallery, IP.Blog и т.д.). Также очень удобно редактировать шаблоны (после включения режима разработки). К сожалению, требует достаточно большого количества ручной работы при разработке и особенно сборке релизов, но большая часть мною уже автоматизирована.
5) Документация вся есть у них на сайте (EN), также можно найти на русском (не вся)
6) Недостатки: присутствует копипаст и говнокод (часть — наследие), баги есть, но оперативно исправляются. Убогий парсер BB-кодов (периодически допиливается).
7) Многоязычность (не полная — в ACP часть строк перевести сразу не несколько языков невозможно, public часть — вся переводиться)
8) Поддержка скинов (+мобильная версия, + xml версия). IE6 не поддерживается. Из коробки присутствуют баги в IE7/8.
9) ЧПУ (несколько видов, поддержка зависит от конкретного приложения)
10) Достаточно требователен к ресурсам
11) Поддержка Sphinx из коробки (можно создавать плагины для собственных приложений)
12) Поддержка кеширования — из коробки использует БД, но одной строкой строкой включается нужный кеш (memcached, eaccelerator, и т.д.)
Основное вроде все, если есть какие либо вопросы могу ответить.
От себя порекомендую книгу: У. Титце, К. Шенк «Полупроводниковая схемотехника». Старая, но написана очень понятно.
Касаемо P-CAD — он разве еще поддерживается?
2 года назад, при написании диплома тоже им пользовался, НО в то время, насколько помню, уже был более современный софт (дальнейшее развитие пикада). Лучше сразу его использовать, т.к. он современнее и главное его трасировщик поддерживает многослойные платы (для пикада тогда была найдена самосборка с этим трассировщиком).
Вы бы хотя бы написали чем отличаетесь от всех остальных? В чем ваши преимущества? Как насчет обмена с другими ПС? Снова все через одно место + дикие проценты? и т.д. и т.п.
Если вы про дерево классов и методов — то да, а вот если про UML — то нет.
> А менять модель, которая обновляет код — вот этого я не хотел бы в своем проекте.
На самом деле очень удобно — добавили классы/интерфейсы/методы их каркасы будут автоматически сгенерированы — останется только наполнить их кодом.
> К слову — а так ли нужны эти диаграммы, если все есть в коде?
Более наглядно и позволяют охватить весь проект целиком (мелкие детали при необходимости можно скрыть). Теоретически можно изменив модель поменять и код (т.к. тела методов можно хранить в диаграмме), но на практике есть трудности.
Это все специфично именно для PHP, для некоторых других языков (тот же Java) проблем намного меньше.
Реализовали каркас, добавили несколько методов (в коде) и классов/интерфейсов. Вторая проблема — а как обновить модель? Часть инструментов это позволяет, НО при этом выясняется что часть информации из модели теряется (а мы старались, делали)… тот же EA*, например, полностью проигнорирует типы аргументов методов (проблеме несколько лет — исправлять её похоже никто не собирается) — придется их восстанавливать. Можно конечно изменять вручную, но это не оправдано и не думаю что кто-то будет это делать для больших проектов (со временем что нибудь забудем и получим расхождение модели и кода).
Попробуем с другой стороны — изменяем модель и пытаемся обновить код — здесь тоже не все гладко… Для EA* например придется вручную указывать соответствие методов в модели и в коде, для больших классов надоест очень быстро.
А вот теперь главный вопрос — оправданы ли все эти затраты? По-моему — нет.
* — Enterprise Architect — самый дешевый моделер с возможностью настройки настройки формата файлов (вроде простая функция, но её нет во многих инструментах)
** — это тоже придется сделать вручную, хотя и один раз (но зато он может занять много времени).
P.S. В ближайшее время собираюсь попробовать Eclipse + Papyrus + Acceleo может и получится что нибудь приемлемое для практического использования.
Это естественно, т.к. разработчиков намного меньше (на фрилансе вообще плохо). Но со временем их станет больше, цены уравняются, и количество быдло кода на python или ruby тоже станет больше (как будто что-то может помешать его написанию).
Этого нет в стандартном варианте. Как и «Отчет за месяц». Хотя может у меня версия старая? (одна из предшествующих 1.0.0 ревизий)
Или это какие-то дополнения?
> 6. Учет бюджета, выставление счетов, проект типа продажа
Этого тоже нет из коробки.
> 8. Контроль прав доступа — каждой группе пользователей назначены свои права;
Не хватает приватных задач. (т.е. если проект общедоступный все видят любые задачи). Ждем 1.1.0.
> 9. Стоимость — open source.
Развиваться вроде медленнее стал
Единственная обработка которая нужная при срабатывании асерта — это исправление ошибки (на дев сервере, на рабочем он все равно никогда не сработает).
> если у вас задумана логика, что если строки локализации нет, то вывести то что есть, так и напишите это в коде:
Так нельзя делать. Обнаружить пропущенную строку при таком подходе невозможно. Это как раз тот случай когда больше всего подходят E_NOTICE (или E_USER_NOTICE).
> представьте себе ситуацию, если вы не проверяете наличие ключа в массиве, этот не существующий элемент массива будет преобразован в null, пустую строку, 0, или false.
Это больше относится к стилю программирования, чем к обработке ошибок… Все нотисы оседают в логи (нотисы я считаю ошибками и при нормальной работе их быть не может) достаточно посмотреть их чтобы обнаружить пропущенную строку (индекс и т.д.). Ну, а на дев сервере нотисы сразу выводятся вместе с трассой (спасибо xdebug) и исправляются при обнаружении.
Зачем здесь исключение?
+ Есть еще E_DEPRECATED/E_USER_DEPRECATED на который вообще нельзя бросать исключение, т.к. код полностью рабочий хотя и устаревший.
+ Часть стороннего кода (в большом проекте он в большинстве случаев будет) может не считать E_NOTICE ошибкой, в вашем случае потребуются костыли чтобы заставить его работать.
> Правильно. Я предлагаю бросать исключения в случае не прохождения утверждения (assertion fail)
Асерты работают только в режиме разработки и служат исключительно для тестирования и отладки кода, т.о.
1) Они НЕ предназначены для обработки ошибок и не могут возникнуть на продакш сервере
2) Переводить их в исключения — нелогично, т.к. это сильно усложнит обработку ошибок + это пустая трата времени (см. п.1)
На хабре, помню, асерты обсуждались очень подробно, но что-то не смог найти :(.
Касательно «не фатальные ошибки» — тоже не согласен. Вы забываете, что не фатальная ошибка (предупреждение, нотис и д.р.), в отличие от исключения НЕ приводит к прерываю работы, т.е. она позволит продолжить работу скрипта и вывести пользователю какие либо данные. Исключение же потребует реализации логики для вывода ошибки и вывода чего-то пользователю. Ну а реагировать на нотис исключением вообще глупо (скажем, не найдена строка локализации — думаете показать пользователю ошибку что её нет лучше, чем просто вывести страницу без неё?)
Добавлю еще один пункт:
X) ВСЕГДА указывайте какие исключения выбрасывает метод (@throws) — в будущем сильно сэкономите время себе и поможете другим разработчикам.
Без последнего пункта весь ваш код со временем выродится — все try блоки будет ловить только базовое исключение, т.к. разработчикам будет лень рыться в чужом коде и искать какие исключения он выбрасывает.
P.S. Хотел PHP проект прогнать, но как выяснилось уже после установки, похоже, нужен проект под maven. Просто так — без maven (только ради sonar-a не хочется его использовать), его нельзя запустить?
Непонятно только как это выглядит с правовой стороны — например, не придет ли потом налоговая за своим процентом? (беглый просмотр документации ничего не дал, если кто-то поделится полезной ссылкой буду благодарен).
Жалко нельзя привязать кошелек отличный R*…
Значит я ошибался :(. Вроде где-то видел что можно отдельно купить… посмотрел в клиентском разделе для форума действительно отдельно не продается (для остальных есть).
> Но при этом доработки за вас уже внесены, что означает отсутствие необходимости ползать по багтрекерам и форумам в поиске решений.
Не все — ни IPS ни IBR (через тиккет можно) не хотят исправлять вывод русских дат в Win системах, хотя в ранних версиях это было.
IBR у меня не ассоциируется с нормальной компанией, например из-за этого — ibresource.ru/products/ipboard/eula/ — сейчас там вместо лицензии выводится страница сайта IPS, когда покупал сам там вообще было «404 Not Found»… (в саппорт об этой и еще нескольких ошибках сообщал).
Каждый сам выбирает что ему важнее
* нормальный доступ к бесплатным ресурсам и некоторые баги (которые можно поправить)
или
* небольшие доработки, получение бесплатных модификаций через достаточно медленную тех. поддержку и отсутствие бесплатных cервисов (кроме генератора скинов)
(сам покупал у IBR, но сейчас взял бы у IPS)
0) Офф. сайт: community.invisionpower.com/ (ссылка на сам форум)
1) Покупать есть смысл только третью версию (скоро выйдет 3.1.0), покупать лучше напрямую у IPS, у IBR — только локализацию (т.к. если купить лицензию не будет доступа к бесплатным ресурсам, которых у IPS достаточно много… модули можно получить через тех поддержку, но отвечает она по несколько дней)
2) Платные: IP.Gallery, IP.Blog, IP.Downloads, IP.Content
3) Также есть бесплатные для клиентов: IP.Tracker (багтрек, используют сами), IP.Shoutbox (чат), и т.д. (можно найти на их сайте)
4) Очень просто разрабатывать модификации (мелкие изменения функционала; в большинстве случаев можно обойтись без модификации кода форума) и приложения (типа IP.Gallery, IP.Blog и т.д.). Также очень удобно редактировать шаблоны (после включения режима разработки). К сожалению, требует достаточно большого количества ручной работы при разработке и особенно сборке релизов, но большая часть мною уже автоматизирована.
5) Документация вся есть у них на сайте (EN), также можно найти на русском (не вся)
6) Недостатки: присутствует копипаст и говнокод (часть — наследие), баги есть, но оперативно исправляются. Убогий парсер BB-кодов (периодически допиливается).
7) Многоязычность (не полная — в ACP часть строк перевести сразу не несколько языков невозможно, public часть — вся переводиться)
8) Поддержка скинов (+мобильная версия, + xml версия). IE6 не поддерживается. Из коробки присутствуют баги в IE7/8.
9) ЧПУ (несколько видов, поддержка зависит от конкретного приложения)
10) Достаточно требователен к ресурсам
11) Поддержка Sphinx из коробки (можно создавать плагины для собственных приложений)
12) Поддержка кеширования — из коробки использует БД, но одной строкой строкой включается нужный кеш (memcached, eaccelerator, и т.д.)
Основное вроде все, если есть какие либо вопросы могу ответить.
P.S. Мнение немного предвзято
Касаемо P-CAD — он разве еще поддерживается?
2 года назад, при написании диплома тоже им пользовался, НО в то время, насколько помню, уже был более современный софт (дальнейшее развитие пикада). Лучше сразу его использовать, т.к. он современнее и главное его трасировщик поддерживает многослойные платы (для пикада тогда была найдена самосборка с этим трассировщиком).
Я лучше на ant-е останусь — уже привык что любое действие можно запустить очень быстро. + к автокомлиту при написании тасков уже привык.
> А возможно это сподвигнет вас к написанию экстеншена для эклипс для удобной работы с phing'ом
Нет — java я настолько хорошо не знаю.