Такая утилита для преобразования css была написана в Яндексе в 2010:
https://github.com/gfranco/jeanny/
Мы использовали её на странице результатов поиска:
https://blog.yandex.ru/post/23106/
Потом отказались, поскольку в JS классы иногда зашиваются в строки и склеиваются, все случаи обработать невозможно и вёрстка иногда ломается после минимизации.
Но если у вас статика без CSS-классов в JS — можно использовать, минификация будет работать.
Ничего нового, или того что нельзя сделать обычным css, кроме идеи с переменными, но их уже реализовывают.
Во-первых, позволяет избежать путаницы в коде с помощью вложенных селекторов… Предположим есть у вас элемент товар и у него есть много вложенных элементов, которые требуют отдельного оформления: цена, описание, кнопка купить, номер модели и прочее. И конечно же теперь придётся писать сто раз подряд li.product тра-та-та…
А запятую для чего придумали? Multiple classes?
и ведь в итоге — код трансформируется именно в них.
только парсером.
зачем этот ужас?
сократить количество кода избавившись от повторяющихся правил… минимизировать код
верстать должны верстальщики, а не программисты и всё будет хорошо, не будет повторяющихся правил, будет нормальный код.
Этот XCSS всё равно на выходе генерит обычный css, только отлаживат этот ужас потом ещё тяжелее будет.
А менеджеры нужны владельцам бизнеса чтобы этого не допустить :) Программисты обычно забывают, что час их работы сейчас стоит для бизнеса дороже, чем через месяц и, тем более, через год, даже если их зарплата не меняется. Мы мыслим линейно: сейчас потратим 8 часов, чтобы потом год каждый месяц не тратить по 1 часу: 8 < 12 — работаем. Для бизнеса же это означает среднесрочное вложение, уменьшающее, как минимум, оборотные средства сейчас ради экономии на них в будущем, а, как максимум, отставание в захвате рынка на 7 часов, которое потом можно компенсировать только многомиллионными вложениями в рекламу и другое продвижение.
Забавно, но я уже который день за месяц просыпаю работу (и при этом по выходным без будильника в 7 утра встаю, блин), в итоге работаю дома (ехать в офис долго — полтора часа). Сделал столько полезного для платформы, на которой пилим продукты, сколько не делал за последние месяца полтора, просто пёрло быстро разгребать накопившиеся мелочи и не только. Коллеги, в том числе и начальство оценили, все счастливы.
Извиняюсь за весь этот код здесь, как-то всё неожиданно произошло. В итоге завернул всё в user.js и положил на гитхаб, вдруг кому-то пригодится: ссылка.
Как говорил Павлов, у ПМ-а под рукой должно быть всегда три вещи: актуальный календарный план (отчитаться перед руководством), шампанское (отпраздновать окончание проекта) и резюме (быстро найти новую работу).
Техническое задание — это техническое задание.
Для Вас, наверное, будет откровением, но когда Вы готовите себе завтрак, Вы выполняете своё техническое задание. Оно может быть разным: покушать, или выпить горячего кофе и покушать, или встать, умыться, нарезать хлеб, налить в чайник воду и т.д.
Так вот, если Вы готовите впервые, неуверенны в себе, плохо готовите или что-то там ещё, то точное ТЗ (встать с правой ноги, перенести вес тела к столу, взять нож за ручку острой стороной лезвия вниз в направлении от себя) Вам будет в любом случае только на пользу.
Если Вы опытный повар, то ТЗ, состоящее из одного «позавтракать» вообще не будет Вам как-то досаждать.
Если говорить о сроках, то Вы же прикидываете, что приготовить быстрокашку, омлет, бутерброд, творожную запеканку займёт примерно столько-то времени.
Поздравляю! Вы можете давать временную оценку своей работе!
И если Вы знаете свою профессию так же неплохо или даже хорошо, то что мешает Вам давать сроки на выполнение своей работы?
Ответьте хоть на один мой вопрос, в конце-то концов. Я ответил на все Ваши.
Вы уходите в дебри: сначала прицепились к часам, потом перекинулись на юридические документы.
Повторю ещё раз: приведите пример Вашей работы, которой нельзя дать временную оценку? Мне не нужны секунды. Раскрой страшную тайну — они никому не нужны. Но если верстальщик режет макет за 1-2 дня, то можно говорить о часах, после того как он взглянет на макет. Если программист пишет какой-либо модуль, то можно говорить и часах или днях, или неделях. Всё зависит от условий — т.е. ТЗ, которое кто-то, возможно даже он сам, заложил для реализации этого модуля.
Вы опять начинаете абстрагировать «а вот если что-то отходит от ТЗ» — да это не тот случай. С этим Вы сами согласились, написав «это верно».
Где пример? Что Вы делали вчера и делаете сегодня? Почему Вы не можете дать оценку по затрате времени на свои действия? У Вас при этом были точные ТЗ?
Кто составляет Вам ТЗ? Вы сами для себя составили хоть одно ТЗ? По сути, всё, то, что Вы планируете — это ТЗ. Почему в личной жизни Вы можете создавать ТЗ и определять на него определённые временные рамки, а на работе — нет?
Либо отвечайте, причём — аргументированно, либо не свистите.
Сравнение «программистов с девушками легкого поведения» довольно распостранено, среди работодателей. Вот только они почему то забывают, что ищут в «борделе» (для нас же разработка — это специальность — средство заработка денег).
Так что хочется напомнить — по-любви — только open-source. На всех остальных мы работаем :)
Несколько уточнений
1. Контора, которую купил Гугл, называлась On2 Technologies
2. VP6 — это старый видеокодек, разработанный On2 Technologies, и широко использовавшийся в Flash-видеоплеерах. К WebM и H.264 прямого отношения не имеет.
3. Когда в Apple сделали выбор в пользу H.264, он был, во-первых наилучшим по качеству/сжатию, а во-вторых очень открытым по меркам индустрии видеокодирования: стандарт видеокодирования доступен бесплатно на сайте ITU (и даже имеет оффициальный русский перевод), и референсная реализация также свободно доступна. Для сравнения, единственный способ встроить VP6 в своё приложение в то время — купить сомнительного качества реализацию кодека у On2 Technologies по специальной цене для вашей компании.
4. Вопреки популярному мнению, кодек H.264 не защищён патентами. Патентами защищены некоторые методы видеосжатия, используемые в этом видеокодеке, причём группа по разработке H.264 приложила усилия к тому, чтобы Base Profile H.264 не использовал никаких патентованых методов. Base Profile даёт на 15-20% больший размер файла по сравнению с High Profile, и примерно сравним с WebM.
5. Компании, владеющими патентами на использованные в H.264 технологиями, договорились что MPEG-LA (licensing authority) будет продавать лицензии сразу на все патенты использованные в H.264 по одинаковым ценам для любой компании, желающей использовать защищённые патентами части H.264. Для программных реализаций лицензия стоит $0.1 — 0.2 за каждую установку.
6. Когда Гугл купил On2 Technologies, он переименовал их последнюю разработку — кодек VP8 — в WebM и стал продвигать его как royality-free альтернативу H.264. При этом, поскольку патентами покрыт не стандарт H.264, а используемые в нём методы кодирования, может оказаться, что и WebM подпадает под патенты.
7. x264, самый популярный видеоэнкодер для H.264, распространяется под GPL.
8. Если бы я был параноиком, то написал бы, что WebM продвигается Гуглом чтобы задавить конкурирующие видеохостинги, которые не имеют ресурсов перекодировать всё их видео в 100500 форматов. Но, к счастью, Гугл не такой я не параноик.
Есть определенные стандарты кодирования, например для php наиболее популярные pear и zend, так вот в них принято использовать пробелы (4 шт) для отступа.
Для питона pep8 настоятельно рекомендует использовать пробелы.
И для ruby рекомендуется использовать 2 пробела (1, 2).
Для javascript Крокфорд рекомендует избегать использования табов.
Понятно что многое из этого просто рекомендации, каждый сам должен для себя решить что использовать, но лично для меня все эти люди и организации являются авторитетными и я свой выбор сделал.
быдлокодить тоже можно красиво… нужен костыль? организовал класс, функцию. прокомментировал ее… и в отдельную папочку положил… вызвал красиво…
Работая в вебстудии, когда все менеджеры получали % с продаж и чем скорее тем лучше, все мои попытки как то все структурировать провалились… как там… «дубась код»
Как минимум первые четыре совета хорошо ложатся на TDD, имхо:
Набрасывайтесь, прежде чем осмотреться — делаем то, что знаем как сделать, подставляя моки и стабы в тех местах где (пока) не знаем.
Перестаньте волноваться о том, как. — тестами мы изолируем, что делает код от того, как он это делает.
Не бойтесь сделать неаккуратно в первый раз. — изолировав мы абстрагируемся от реализации, она может быть неаккуратной, но мы её всегда можем поправить
Не бойтесь переписывать код. — тесты дают нам уверенность, что переписывание кода не изменит его (документированной) функциональности.
https://github.com/gfranco/jeanny/
Мы использовали её на странице результатов поиска:
https://blog.yandex.ru/post/23106/
Потом отказались, поскольку в JS классы иногда зашиваются в строки и склеиваются, все случаи обработать невозможно и вёрстка иногда ломается после минимизации.
Но если у вас статика без CSS-классов в JS — можно использовать, минификация будет работать.
MCSS может пригодится только на очень большом, монолитном проекте.
Ничего нового, или того что нельзя сделать обычным css, кроме идеи с переменными, но их уже реализовывают.
А запятую для чего придумали? Multiple classes?
и ведь в итоге — код трансформируется именно в них.
только парсером.
зачем этот ужас?
верстать должны верстальщики, а не программисты и всё будет хорошо, не будет повторяющихся правил, будет нормальный код.
Этот XCSS всё равно на выходе генерит обычный css, только отлаживат этот ужас потом ещё тяжелее будет.
Техническое задание — это техническое задание.
Для Вас, наверное, будет откровением, но когда Вы готовите себе завтрак, Вы выполняете своё техническое задание. Оно может быть разным: покушать, или выпить горячего кофе и покушать, или встать, умыться, нарезать хлеб, налить в чайник воду и т.д.
Так вот, если Вы готовите впервые, неуверенны в себе, плохо готовите или что-то там ещё, то точное ТЗ (встать с правой ноги, перенести вес тела к столу, взять нож за ручку острой стороной лезвия вниз в направлении от себя) Вам будет в любом случае только на пользу.
Если Вы опытный повар, то ТЗ, состоящее из одного «позавтракать» вообще не будет Вам как-то досаждать.
Если говорить о сроках, то Вы же прикидываете, что приготовить быстрокашку, омлет, бутерброд, творожную запеканку займёт примерно столько-то времени.
Поздравляю! Вы можете давать временную оценку своей работе!
И если Вы знаете свою профессию так же неплохо или даже хорошо, то что мешает Вам давать сроки на выполнение своей работы?
Ответьте хоть на один мой вопрос, в конце-то концов. Я ответил на все Ваши.
Вы уходите в дебри: сначала прицепились к часам, потом перекинулись на юридические документы.
Повторю ещё раз: приведите пример Вашей работы, которой нельзя дать временную оценку? Мне не нужны секунды. Раскрой страшную тайну — они никому не нужны. Но если верстальщик режет макет за 1-2 дня, то можно говорить о часах, после того как он взглянет на макет. Если программист пишет какой-либо модуль, то можно говорить и часах или днях, или неделях. Всё зависит от условий — т.е. ТЗ, которое кто-то, возможно даже он сам, заложил для реализации этого модуля.
Вы опять начинаете абстрагировать «а вот если что-то отходит от ТЗ» — да это не тот случай. С этим Вы сами согласились, написав «это верно».
Где пример? Что Вы делали вчера и делаете сегодня? Почему Вы не можете дать оценку по затрате времени на свои действия? У Вас при этом были точные ТЗ?
Кто составляет Вам ТЗ? Вы сами для себя составили хоть одно ТЗ? По сути, всё, то, что Вы планируете — это ТЗ. Почему в личной жизни Вы можете создавать ТЗ и определять на него определённые временные рамки, а на работе — нет?
Либо отвечайте, причём — аргументированно, либо не свистите.
Так что хочется напомнить — по-любви — только open-source. На всех остальных мы работаем :)
1. Контора, которую купил Гугл, называлась On2 Technologies
2. VP6 — это старый видеокодек, разработанный On2 Technologies, и широко использовавшийся в Flash-видеоплеерах. К WebM и H.264 прямого отношения не имеет.
3. Когда в Apple сделали выбор в пользу H.264, он был, во-первых наилучшим по качеству/сжатию, а во-вторых очень открытым по меркам индустрии видеокодирования: стандарт видеокодирования доступен бесплатно на сайте ITU (и даже имеет оффициальный русский перевод), и референсная реализация также свободно доступна. Для сравнения, единственный способ встроить VP6 в своё приложение в то время — купить сомнительного качества реализацию кодека у On2 Technologies по специальной цене для вашей компании.
4. Вопреки популярному мнению, кодек H.264 не защищён патентами. Патентами защищены некоторые методы видеосжатия, используемые в этом видеокодеке, причём группа по разработке H.264 приложила усилия к тому, чтобы Base Profile H.264 не использовал никаких патентованых методов. Base Profile даёт на 15-20% больший размер файла по сравнению с High Profile, и примерно сравним с WebM.
5. Компании, владеющими патентами на использованные в H.264 технологиями, договорились что MPEG-LA (licensing authority) будет продавать лицензии сразу на все патенты использованные в H.264 по одинаковым ценам для любой компании, желающей использовать защищённые патентами части H.264. Для программных реализаций лицензия стоит $0.1 — 0.2 за каждую установку.
6. Когда Гугл купил On2 Technologies, он переименовал их последнюю разработку — кодек VP8 — в WebM и стал продвигать его как royality-free альтернативу H.264. При этом, поскольку патентами покрыт не стандарт H.264, а используемые в нём методы кодирования, может оказаться, что и WebM подпадает под патенты.
7. x264, самый популярный видеоэнкодер для H.264, распространяется под GPL.
8. Если бы я был параноиком, то написал бы, что WebM продвигается Гуглом чтобы задавить конкурирующие видеохостинги, которые не имеют ресурсов перекодировать всё их видео в 100500 форматов. Но, к счастью,
Гугл не такойя не параноик.Для питона pep8 настоятельно рекомендует использовать пробелы.
И для ruby рекомендуется использовать 2 пробела (1, 2).
Для javascript Крокфорд рекомендует избегать использования табов.
Понятно что многое из этого просто рекомендации, каждый сам должен для себя решить что использовать, но лично для меня все эти люди и организации являются авторитетными и я свой выбор сделал.
Работая в вебстудии, когда все менеджеры получали % с продаж и чем скорее тем лучше, все мои попытки как то все структурировать провалились… как там… «дубась код»
Набрасывайтесь, прежде чем осмотреться — делаем то, что знаем как сделать, подставляя моки и стабы в тех местах где (пока) не знаем.
Перестаньте волноваться о том, как. — тестами мы изолируем, что делает код от того, как он это делает.
Не бойтесь сделать неаккуратно в первый раз. — изолировав мы абстрагируемся от реализации, она может быть неаккуратной, но мы её всегда можем поправить
Не бойтесь переписывать код. — тесты дают нам уверенность, что переписывание кода не изменит его (документированной) функциональности.
К неподдерживаемому в IE9