Пользовался Elementary OS в течении года. Сначала поставил на домашний комп версию Luna, затем на рабочий Freya.
Если с Luna хоть как-то можно было жить, то Freya оказалось на столько проблемной, что через пол года я её снес в пользу Ubuntu и совсем не жалею.
Вабще непонятно зачем разработчикам упарываться в легковесные браузеры и почтовые клиенты, когда сама ОС нуждается в исправлении простейших багов — с клавиатурой и выпадающем меню например. А браузеры и почтовые клиенты уже есть неплохие под линукс.
Пусть они читаются не так лаконично, зато исключается всякая двусмысленность.
Исключить двусмысленность можно грамотной проработкой моделей и изучением предметной области перед началом работы с кодом.
А в чём заключается неуниверсальность?
К примеру, если вы решите реализовать описанную моделями логику в виде объектно-ориентированной СУБД или, ещё проще, диаграммы классов, то постфикс Model будет избыточен.
У меня есть ещё одно замечание, не описанные выше в комментариях. Связано оно именно с проектированием приложения.
При разработке ПО есть уровень проектирования, а есть уровень реализации.
На уровне проектирования находятся модели со своими связями и они должны быть предельно просто и понятно описаны:
User->cart->item->name
Catalog->item->price
Это нужно для того, чтобы при разработке структуры базы данных и диаграммы бизнес-процессов вы говорили на одном языке с руководством и исполнителями, не важно через доклад, схему или код.
После уровня проектирования идет уровень реализации, это то место где модели обретают связь с особенностями реализации сайта в выбранной вами платформе.
Так модель получает контроллер, шаблон и прочие классы завязанные на модель: UserController, UserValidator, UserForm и т.п.
Если вы будете на уровне проектирования использовать вспомогательный синтаксис сайта, особенно Yii, то описание вашей модели данных будет не универсальным и понятным лишь узкому кругу специалистов — программистам Yii, которых вы посвятили в свои правила.
Делали несколько лет назад аналогичный проект.
По опыту многих лет скажу:
1) ГИБДД неохотно идет на контакт с такими проектами
2) Народ как прибывает, так и убывает, так как реальной пользы от проекта очень мало. У нас из ~40 случаев только по 4 привлекли нарушителей к ответственности, в остальных дела затягивали и приостанавливали.
3) Была задумка сделать андродид-приложение с распознаванием номеров авто и скачиванием по ним информации с сайта. Уперлись в сложность разработки, смартфоны работают очень медленно с OpenCV.
4) Монетизировать нужно рекламой на пике популярности, мы, увы момент упустили (думали что будем делать некоммерческий проект:)).
После поездки на море на автомойке я плачу лишних 50 рублей, чтобы мне промыли днище авто от соли, иначе начнет ржаветь.
Совсем не представляю себе использование автомобиля полностью погружаемого в соленую воду, это же какое у него должно быть ЛКП?
Если с Luna хоть как-то можно было жить, то Freya оказалось на столько проблемной, что через пол года я её снес в пользу Ubuntu и совсем не жалею.
Вабще непонятно зачем разработчикам упарываться в легковесные браузеры и почтовые клиенты, когда сама ОС нуждается в исправлении простейших багов — с клавиатурой и выпадающем меню например. А браузеры и почтовые клиенты уже есть неплохие под линукс.
Пробовал UTF-8 и Windows-1251. В результате у него в базе все в иероглифах.
Если у кого-то есть предложения по совместному развитию autoimho.com — пишите)
Исключить двусмысленность можно грамотной проработкой моделей и изучением предметной области перед началом работы с кодом.
К примеру, если вы решите реализовать описанную моделями логику в виде объектно-ориентированной СУБД или, ещё проще, диаграммы классов, то постфикс Model будет избыточен.
При разработке ПО есть уровень проектирования, а есть уровень реализации.
На уровне проектирования находятся модели со своими связями и они должны быть предельно просто и понятно описаны:
User->cart->item->name
Catalog->item->price
Это нужно для того, чтобы при разработке структуры базы данных и диаграммы бизнес-процессов вы говорили на одном языке с руководством и исполнителями, не важно через доклад, схему или код.
После уровня проектирования идет уровень реализации, это то место где модели обретают связь с особенностями реализации сайта в выбранной вами платформе.
Так модель получает контроллер, шаблон и прочие классы завязанные на модель: UserController, UserValidator, UserForm и т.п.
Если вы будете на уровне проектирования использовать вспомогательный синтаксис сайта, особенно Yii, то описание вашей модели данных будет не универсальным и понятным лишь узкому кругу специалистов — программистам Yii, которых вы посвятили в свои правила.
Аудиторию напрягало отсутствие решения проблемы, поэтому наверное и разбежались.
Тогда есть шанс привлечь владельца тс.
По опыту многих лет скажу:
1) ГИБДД неохотно идет на контакт с такими проектами
2) Народ как прибывает, так и убывает, так как реальной пользы от проекта очень мало. У нас из ~40 случаев только по 4 привлекли нарушителей к ответственности, в остальных дела затягивали и приостанавливали.
3) Была задумка сделать андродид-приложение с распознаванием номеров авто и скачиванием по ним информации с сайта. Уперлись в сложность разработки, смартфоны работают очень медленно с OpenCV.
4) Монетизировать нужно рекламой на пике популярности, мы, увы момент упустили (думали что будем делать некоммерческий проект:)).
Возможно вам удастся добиться больших успехов.
Есть альтернативный способ сохранения энергии — в супермаховиках.
Интересно, когда они станут популярны.
Совсем не представляю себе использование автомобиля полностью погружаемого в соленую воду, это же какое у него должно быть ЛКП?