На вкус и цвет фломастеры разные. Но как по мне, лучше scss потому что верстальщик не будет пугаться, если ему дать питоноподобный документ со стилями. SCSS универсальнее, хоть чуток и менее удобный.
Ну вон в SASS тоже так думали, но почему-то появился LESS, а потом SCSS и как оказалось, они оба стали намного популярнее старого SASS с его диковенным питон-стайл синтаксисом.
Это хорошо, что можно писать меньше кода. Но возможность вставлять обычный яваскриптовский код, править его с учетом новых возможностей, могло бы быть очень полезной фичей и лишало бы чистый Javascript всех его преимуществ. Сейчас же, на Coffee перейдут только программисты что хорошо знают руби и не особо используют яваскрипт.
Я чуть не о том говорил, а о том, что синтаксис технологий, которые должны заменять нативные технологии, должен быть максимально к ним приближен. Чтобы, например, нативный JS-код, мог выполняться в среде Coffee без всяких там апострофов, в которые его оборачивают.
Они не учитывают одну штуку, а именно, насколько их новая технология совместима со старой.
Например, HAML, как по мне штука неудачная — использует свой синтаксис, очень привредлива в форматировании кода, в сложных конструкциях всё так же можно запутаться, как в HTML.
А вот SASS 3 вещь хорошая и нужная, потому что она сделана с синтаксисом css и совместима с css3.
HAML не решает ничего такого, что нельзя было бы решить в обычном HTML, а SASS как раз решает многие проблемы, и по сути определяет направление, к которому будет двигаться CSS.
Я к тому, что не все «заменители» одинаково полезны. Если верстальщику нужно полчаса на покурить документацию SASS, то ему понадобиться пару дней (или больше), чтобы привыкнуть к синтаксису HAML. То же и с CoffeeScript — вопрос, сколько времени займет осиливание их синтаксиса у JS-разработчиков, непонятно. Также непонятно, насколько оно нужно — жертвовать универсальностью ради удобства.
Ну везде нужно искать где это рационально выгодно, а где нет. В случае с БД, я согласен с коллегой, проще гонять тесты на in-memory database, при этом вариант моков никак не спасает. Ведь тогда, допустим, при изменении методов модели, придется также менять моки, чтобы код выполнялся одинаково. Таким образом мы приходим к тому, что мы или пишем код дважды, или в лучшем случае, нам приходится править больше файлов, чтобы актуализировать тесты.
Юнит-тесты отличная штука там где классы более-менее изолированы, это факт. Там где добавляется persistance или view, лучше перебдеть и написать все возможные команды в функциональных тестах, на что и времени потратиться меньше, и уверенности в работоспособности системы вцелом будет больше.
Если это гавнокод, то есть толко два варианта:
— мучаться и дописывать в чужой гавнокод свой, и тут иначе никак, ты не получится менять чужие конструкции, без риска завалить весь проект. А потому и свой код будешь делать максимально изолированым от чужого, чтобы ни в коем случае не повредить ничего, и в итоге пишешь гавнокод.
— покрыть всё функциональными тестами и переписать всё. Но на это обычно нет ни времени, ни возможности, и вообще это крайне редкое явление.
Ну он очень грамотно скрывается, это раз. Ну и как было отмечено, для широкоформатников выделить колонку слева менее напряжно чем, как в старом гноме 4 панели: вернхяя полоска, заголовок, меню, нижняя полоска.
В итоге, на экране одна полоска и простой доступ ко всем приложениям через Win + Hotkeys
Почитал обзор… Может он и прав. Для меня такая вещь как рабочее пространство достаточно важная вещь, хоть и у меня монитор 21". А в Гноме как-то действительно оно не оптимизировано.
Вообщем, предчувствую, что если допилять Юнити, останусь на нем. Что нравится — слишком много в нем через клавиатуру решается, да и всё достаточно удобно и просто сделано.
Вот только мне интересно что ж это за проект такой где по умолчанию юзался sqlite…
Я быстро вкурил HAML, и потом долго его выкуривал, ибо появился Zen coding и преимущества Хамла мне стали не столь очевидны.
А вот SCSS + Compass я юзаю во всех своих проектах, даже тех, что не Ruby on Rails.
Это хорошо, что можно писать меньше кода. Но возможность вставлять обычный яваскриптовский код, править его с учетом новых возможностей, могло бы быть очень полезной фичей и лишало бы чистый Javascript всех его преимуществ. Сейчас же, на Coffee перейдут только программисты что хорошо знают руби и не особо используют яваскрипт.
Например, HAML, как по мне штука неудачная — использует свой синтаксис, очень привредлива в форматировании кода, в сложных конструкциях всё так же можно запутаться, как в HTML.
А вот SASS 3 вещь хорошая и нужная, потому что она сделана с синтаксисом css и совместима с css3.
HAML не решает ничего такого, что нельзя было бы решить в обычном HTML, а SASS как раз решает многие проблемы, и по сути определяет направление, к которому будет двигаться CSS.
Я к тому, что не все «заменители» одинаково полезны. Если верстальщику нужно полчаса на покурить документацию SASS, то ему понадобиться пару дней (или больше), чтобы привыкнуть к синтаксису HAML. То же и с CoffeeScript — вопрос, сколько времени займет осиливание их синтаксиса у JS-разработчиков, непонятно. Также непонятно, насколько оно нужно — жертвовать универсальностью ради удобства.
Юнит-тесты отличная штука там где классы более-менее изолированы, это факт. Там где добавляется persistance или view, лучше перебдеть и написать все возможные команды в функциональных тестах, на что и времени потратиться меньше, и уверенности в работоспособности системы вцелом будет больше.
— мучаться и дописывать в чужой гавнокод свой, и тут иначе никак, ты не получится менять чужие конструкции, без риска завалить весь проект. А потому и свой код будешь делать максимально изолированым от чужого, чтобы ни в коем случае не повредить ничего, и в итоге пишешь гавнокод.
— покрыть всё функциональными тестами и переписать всё. Но на это обычно нет ни времени, ни возможности, и вообще это крайне редкое явление.
В итоге, на экране одна полоска и простой доступ ко всем приложениям через Win + Hotkeys
Вообщем, предчувствую, что если допилять Юнити, останусь на нем. Что нравится — слишком много в нем через клавиатуру решается, да и всё достаточно удобно и просто сделано.
А вот прочие глюки…