Для своих веб-проектов, папка [WWW] в корне диска.
Для других типов проектов - [Мои проекты] (в корне диска).
Рабочие - папка с названием компании в корне диска.
Скобки - для сортировки в дереве файлов (это под Windows).
В последнее время подумываю, что нужно отдельные диски для этого заводить :-)
Т.е. минимум три диска, ну или два: свои проекты и рабочие. Было бы удобней.
Структура внутри папки проекта, в моем случае, диктуется Visual Studio.
Раньше делал отдельную папку Releases для каждого проекта, это слишком муторно. Сейчас не делаю. Сам свои выпуски, если понадобятся, ищу в публичных источниках, куда опубликовал :-)
Публичные проекты с открытым исходным кодом имеют немного другую структуру и многие файлы я не публикую. Делаю один раз для GitHub, потом копирую на другие ресурсы (SourceForge, CodePlex и т.п.). В публичном проекте обычно есть папка /bin - для сборок, и /src - для исходного кода. Также может быть документация в корне проекта (файл или папка).
В локальных/приватных системах контроля версий (или ветках) разделения проектов на группы нет, все в кучу складывается, по папкам проектов.
Да, в каждом новом обновлении приходят маленькие вирусы, которые внедряется в ядро системы и грызут его, грызут! :-)
Windows XP много лет прекращали поддерживать. Вероятно и с семеркой будет аналогично.
Скорее всего обновления касаются проблем с безопасностью, их точно еще долго будут исправлять. Ну и серьезные ошибки тоже должны исправляться. Просто развития этой версии больше не будет.
Сделать проект для сбора идей у населения. Хотя это не оригинальная идея.
Не думаю, что кто-то поделится чем-то таким, чего еще не существует и что, в теории, может привести к увеличению доходов создателей. Хотя нет, вот Наполеон из соседней палаты говорит, что можно сделать сайт, на котором каждый сможет захватить весь мир. Впрочем, это тоже не ново ;-)
Удалил свой ответ, т.к. он неверный. Если интересны сделанные мной для удаленного ответа исправления, посмотреть можно тут: jsfiddle.net/alekseynemiro/mk2ph3tn
При правильном использовании, LESS и S(A|C)SS позволяют упростить исходный код, облегчить процесс разработки стилей.
Из некоторых фишек, которые я вывел для себя:
0. Разбиение "проекта стилей" на части и удобная сборка на выходе.
1. Вложенные стили - довольно удобно использовать. Исходный код красивее и понятней.
2. Переменные. При правильном использовании, можно легко менять стили, сделав какой-нибудь файл конфигурации.
3. Наследование стилей - можно определить базовые стили и использовать.
4. Циклы - можно, например, сделать стили для разных разрешений экранов, определив их всего один раз.
Еще спрайты - группировка небольших изображений в одно. Но это уже косвенно к теме относится.
Из минусов:
0. Сложность поддержки. Нельзя просто взять и поменять стили, их придется пересобирать.
1. Видел много излишне сложных "стилевых" проектов. Не понимаю, как элементарные вещи можно так сильно усложнять :-)
2. Повышаются требования к front-end разработчику, и, как следствие, стоимость работ. Школьника для такой работы уже нанять не получится.
Группировка в данном случае не имеет смысла. Вот если было более сложное условие, типа: if(($abc == 123 || $uTest == 1) && $uTest_2 == 2), тогда для правильной работы и лучшего понимания условия, было бы необходимо сгруппировать отдельные блоки.
