#meetrailslove – May 2012

Like every month there are some awesome events coming up. Here are a few – and at some you can #meetrailslove:

On the international scene the DLD Moscow is happening from 27th – 29th May, 2012. Check out Moscow calling DLD.

For more events check out this and this event calendars.

We wish you a very eventful May!

April 24, 2012 | Filed Under devhousefriday, nerdpursuit, rails, Railslove, Railslove on Tour, ruby, webmontag

1 Comment 

SMACSS and SASS – The future of stylesheets

I just had the the pleasure of attending the SMACSS workshop in Essen by Jonathan Snook (@snookca) and wanted to share my impression of the “SMACSS approach” to CSS and some considerations on using it together with SASS.

Overview: The philosophy behind SMACSS

On a high level SMACSS aims at changing the way we are turning designs into code (here CSS+HTML).  Instead of working in a “page mentality” where you look at a single page’s design and try to find the best way of turning that page into code, SMACSS advocates taking a step back and trying to identify repeating visual patterns. Those patterns are then supposed to be codified into flexible modules, which should be as independent as possible from the individual page context.  This might not sound so revolutionary from a programmer’s point-of-view, but for the web design community this is indeed a new(er) way of thinking.  I myself kind of think of it as “data modeling from the other side“ instead of trying to structure information (into e.g. a database schema) you are trying to structure visual design into a CSS module architecture.

Related Works

Even for CSS such an approach is not entirely new, but in my opinion SMACSS presents it in a very accessible (=> public website),  approachable and pragmatic way.  It has many basic ideas in common with the likes of OOCSS, CSS Lint and similar “modular CSS” advocates, but I would say it is less strict and “hardcore” about it.  For example, instead of saying “You should never ever use element selectors!”, it rather advocates to keep them to a minimum, and still use them where it makes (semantic) sense.

Concept of categorization

The basic concept of SMACSS is to categorize styles into 4* categories: base, layout, modules and states.  Each category comes with a set of more ore less loosely defined naming conventions and usage rules.

Base

This is where things like CSS resets (if you use them), element defaults (e.g. link colors), default font sizes, etc. belong.  The category is largely dominated by element selectors.  However, you should always ask yourself “Is this base?” in order to not loose flexibility down the road.

Layout

This includes all types of layout containers such as header, footer, content, sidebar, etc.  The layout elements don’t really have any styles of their own, but are simply containers.  Obviously, this is the layer where grid systems would be living.  All selectors in this category should be prefixed with .layout- (e.g. .layout-header, .layout-sidebar).

Modules

The bulk of (SMA)CSS is made up of independent modules and submodules.  Examples for modules could be things like: search-box, dialog, navigation, menu, content-box.  While submodules are more specific versions of these modules such as:  dialog-wide, navigation-tabbed, menu-dropdown.
The ideal module is completely independent of its context and should work within any layout container or other module.  If a specific context requires changes to a module you rather create a submodule that describes the context, instead changing styles based on the parent (e.g. .content-box-narrow instead of #sidebar .content-box).

States

Modules can have different types of states:  class-based states (.is-hidden), pseudo-classes (:hover, :focus), attribute states (data-state=transitioning), or @media query states.  These states belong right to the modules but have a separate category because they have their own naming convention and usage rules.

The back-story behind SMACSS

I think there are two important things to mention in order to understand where SMACSS is coming from and where it makes most sense.  The first is about the role and team setup and the second about the type of product it is designed for.

SMACSS is designed for a “Prototyper” job description, who turns design comps into HTML+CSS, before they are passed on to the engineers.  If you have a less rigid, more agile developing process, where maybe one engineer works on both the front- and the backend (e.g. in a startup context), you probably need to cut some corners when implementing SMACSS. Also, the approach is ideally accompanied by a prototyping system/tool, where you create testing templates for each of the defined modules in order to visually test them – both on their own and within other modules and layout containers.  Jonathan Snook and his team at Yahoo were using such a custom build system for Yahoo Mail, but something like it yet has to be made publicly available for generic projects.  In my opinion this is a very interesting and promising direction to have TDD-like tools for visual testing of frontend code.  Looking forward to that!

Secondly, the SMACSS approach was born out of experiences building Yahoo Mail and therefore it makes most sense for web “applications” and not so much for web “sites”.  The application ideally needs to consist of easily definable modules which are long-lived and appear in different contexts, otherwise creating proper SMACSS modules might just be overhead.  The same is probably true, for parts that are a little separate from the application and undergo a lot of design changes, such as landing pages or other ephemeral site areas.  Here it might not always make sense to modularize everything.

SASS + SMACSS = ?

Themes

When I was talking about SMACSS having 4 categories earlier, I actually left out the 5th category which is “theme”.  I did this because, when using SASS, theming can easily be handled by defining variables for the style properties that you want to be themeable (e.g. $themable-border-color), instead of having to apply special classes to all the themable elements (.theme-border).  Here at Railslove we just had to create a new theme (basically a re-branding with different colors) on short notice for our client 9flats.com and we were amazed how quickly we could complete this task on a SASS-based website, which would have taken much longer in “the old days”.

Submodules

The best and most straightforward application of SASS functionality to the SMACSS approach is for submodules.  Whenever you need a variation of one of your modules, you are supposed to create a submodule, e.g. .dialog-wide is a submodule of .dialog.  While in traditional SMACSS you would need to apply both classes to your element (<div class="dialog dialog-weide" >), using SASS you have the perfect use case for the (underutilized) @extend feature and you would simply do it this way:

.dialog
  width: 300px
  color: blue

.dialog-wide
  @extend .dialog
  width: 600px

The only thing you need to be aware of, is to never to extend across modules, which would violate the concept of SMACSS and could easily lead to unwanted side effects.

Module component syntax

One thing that I haven’t quite made up my mind about is the syntax within modules.  SMACSS proposes that every component within a module should have a) its own selector (for performance) and b) be prefixed with the module name (for clarity). Like this:

.dialog
  width: 500px

.dialog-header
  font-weight: bold

.dialog-body
  font-size: 13px

This syntax is in some conflict with the way I have gotten used to authoring stylesheets with SASS, making heavy (sometimes too heavy) use of its nesting capabilities & syntax.  Using my traditional SASS style, it would probably look something like this:

.dialog
  width: 500px
  .header
    font-weight: bold
  .body
    font-size: 13px

I feel that all the prefixing adds a lot of distracting verbosity to the stylesheet and by nesting all the components underneath the module selector it actually gives it a nice visual closure.  The important requirement here is that you keep the component number and nesting depth of your module to a minimum.  But I think in this case applying the modular SMACSS philosophy is actually one of the best things that could happen to SASS, because the best practice to minimize your nesting has been pushed too little and therefore been overlooked far too often by SASS practitioners.  However, the big downside with this approach is that you loose a lot of clarity in the markup, because now it’s not obvious anymore to which module a component class such as .header belongs to.  One idea to alleviate this problem could be to have a more obvious naming convention for module selectors (e.g. .module-dialog), so it’s easier to trace your way up in the markup from a component class to the next module selector it belongs to.

The other more minor downside of nesting would be the loss in CSS performance due to longer selectors caused by nesting.  However, unless you are not working on a super high performance website with massive reflows, lots of old browsers and complex mobile requirements, most  sources [1, 2, 3, 4] make me believe that heavily optimizing for CSS performance, isn’t really worth the effort, especially in a startup environment.

So, if we say that, on the one side we don’t care so much about CSS performance and we do like the visual clarity of SASS nesting, but on the other side we also like the idea of always knowing which components belong to each other based on prefixes, a syntax like this could actually be a compromise:

.dialog
  width: 500px
  .dialog-header
    font-weight: bold
  .dialog-body
    font-size: 13px

If you then should start to worry about performance at some point you can easily convert to pure SMACSS.  However, I myself am not really sure yet what syntax I really prefer.  What do you think?

File structure

SMACSS already includes quite sensible naming conventions for selectors, but coming from the Rails/SASS world we obviously also value conventions for our file structure.  My suggestion for a SMACSS+SASS file structure would probably look something like this:

+ applications.sass                  // @imports
+ base/
|    _settings.css.sass              // SASS config variables
|    _reset.css.sass
|    _colors.css.sass
|    _fonts.css.sass
|    _element_defaults.css.sass
|    _form_defaults.css.sas
+ layout/
|    _settings.css.sass              // SASS layout/grid variables
|    _containers.css.sass
+ modules/
+ non-modular/

I guess there is nothing too surprising in there.  The only thing that I would add is the folder/area for non-modular styles.  As I said earlier there are always cases for pages/styles that are not very long-lived, not “fully baked”, and so on.  Those should go to the non-modular folder.  Here it probably also makes sense to write highly specific (maybe even controller/view-specific) styles.  With that I would just want to prevent any half-assed styling attempts to bleed into the modular styles.  If styles in there last longer than expected, you can always go back and “graduate” them to proper SMACSS modules.

Concerning file structure there is a little shell script by Wynn Netherland to create a (much simpler) SMACSS folder structure for SASS, maybe this could be extended for further integration between the two.

Submodule vs. component syntax

The last little thing I want to talk about is a small issue I have with the SMACSS syntax and that is the indifference between the syntax for submodules vs. module components.  If you have for example a selector such as .navigation-header, this could either be a submodule of the .navigation module (submoduled for the header context), or it could be a component of the .navigation module assigned to the header element of the navigation.  It’s not a big issue, but I nevertheless think it would be valuable to be able to discriminate the two on first sight.  Jonathan mentioned that a suggestion for differentiation, that was brought up, was to use two -- vs. one - dashes, e.g. .navigation--header (I think for the component) vs. .navigation-header (for the submodule).  Not sure that this is the ideal solution, but I truly think that it would be very good being able to differentiate them.

tl;dr

SMACSS is a very user-friendly approach to modular CSS.  It asks for nothing less than a complete shift from a “page mentality” towards webdesign, to a search and codification of visual patterns.  For that it offers a concise and sensible categorization and naming scheme.
It generally goes along very well with SASS, especially using the @extend feature and when it comes to themeing.  It’s kind of an open question how SASS’s nesting capabilities fit with SMACSS, but in general I think it can bring lots of very valuable and badly needed modularity and conventions to the SASS/Rails community.

March 28, 2012 | Filed Under CSS, OSS, rails, Railslove, SASS

14 Comments 

We @ Wroc_❤.rb and we ❤ Vention Dention

We’re proud to announce wroc_love.rb 2012. The very first of such conferences in a beautiful city of Wrocław. What is this conference about?

A fresh Ruby conference organized by thriving local Ruby community. We’re keen on experimenting, value original ideas and diversity of opinions – as long as they’re backed with valid arguments.

You can meet : Georg, Bumi, Mike, Ralph, myself and our friend Nick.

We’re giving a talk

What is our talk about? About.. “Pit .. Brad Pit..Pit’s..ahhr! Just get out of the trap!!!” In our talk we will share some of the most interesting, absurd, or funny moments and insights we have experienced in past couple of years. As developers and business founders, we present the best of our own mistakes and show you how we got out of the pits we fell into. Believe us, we’ve been there as well and, hopefully, attending our talk will help you not make our mistakes. ;) It will be a serious fun! The talk will cover both technical and other subjects. Each mistake will get a 2-3 min coverage. Read more about us and our talk at the conference page and on their blog.

We love punk rock

Did you know we have our own band? No? Ok… now you know it! We’re proud to indroduce you to…

Vention Dention

Oh yeah. Vention Dention is on tour again… and we’re with them all the time. So the next gig’s are:

We’re planing some more gigs with them and everything will be announced on their homepage, on Railslove’s Vention Dention Homepage and via Twitter (@ventiondention). So stay tuned!

For now, just for you… Vention Dention:

Vention Dention Logo Animated

Vention Dention Logo Animated

See you @ wroc_love.rb!

January 31, 2012 | Filed Under conference, rails, Railslove, Railslove on Tour, vention dention

Comments Off 

Help You need somebody; Help not just anybody!

Here at Railslove, we love building web applications. But aside from our core business, we also help other startups understand how the web works and what it means to run a web business — in Hamburg, Berlin, Cologne. And since experienced Ruby on Rails developers are increasingly hard to find, we’ve started to offer apprenticeships, too.

One of our new partners is DailyDeal. We’ve done some beginners and advanced courses in Rails covering stuff like testing, building APIs, advanced JavaScript coding and general design and programming patterns in Ruby on Rails, etc.

Oliver Hepfner, Director Software Engineering of DailyDeal:

The training Railslove provided under the direction of Georg Leciejewski helped us understand advanced programming patterns in Ruby on Rails. Our developers were excited to get a hands-on introduction into Ruby on Rails.

 

Next month, we will launch a few more courses with DailyDeal and with other companies, like Adcloud GmbH in Germany. If you are interested in learning more, please contact Ralph and Georg: ralph AT railslove.com & gl AT salesking.eu & team AT railslove.com

October 12, 2011 | Filed Under javascript, rails, Railslove, Railslove on Tour, ruby

Comments Off 

Travis – a distributed build system

Let us introduce us to Travis. What is Travis? As you can read on Github:

Travis is an attempt to create an open-source, distributed build system for the Ruby community that:

  1. allows open-source projects to register their repository and have their test-suites run on demand
  2. allows users to contribute build capacities by connecting a VM that runs a build agent somewhere on their underused servers

Travis Logo You can and should use travis for your open source projects as an continuos integration system. Travis is an incredible project and helps increase the quality of  lots of Open Source projects. So please head over to travis and setup tests for your ruby, node.js, erlang, … projects. – you can also setup your own instance installing Travis and use it for your private projects.

For more information check out the github page and the getting started section.

We’re really happy to be able to support Travis by sponsoring one of the worker boxes.

btw. Sven, Josh, thanks for mentioning us on your talks at Ruby Lugdunum and Frozen Rails 2011 this year. ;)

Btw.: have you heard about the Awesome Bot Factory? With the Awesome Bot Factory you’re able to create bots for your campfire channel. There is a bot to integrate travis to your campfire chat: simply ask the bot for a given status, like:

Jan travis:status Nerds/NerdPursuit
Choco Bits Bot Nerds/NerdPursuit is stable

Or get notified about your project’s new travis builds.

- Thank you, Travis-CI!

Resources:

October 3, 2011 | Filed Under continious integration, Cool stuff on GitHub, rails, Railslove

Comments Off 

Next Page →