imported latest blog posts from wordpress

posts/2008-04-08-impressum.markdown

@@ -0,0 +1,28 @@
+---
+title: Impressum
+slug: impressum
+author: tim_schneider
+published: true
+author_name: Tim
+author_email: tim@railslove.com
+author_url: http://railslove.com
+wordpress_id: 13
+wordpress_url: http://blog.railslove.com/?page_id=13
+published_at: 2008-04-08 10:43:48.000000000 +02:00
+categories:
+- railslove
+---
+Railslove GbR
+Michael Bumann, Jan Kus, Tim Schneider
+
+Gothaer Allee 2
+50969 Köln
+
+Tel.: +49 176 - 22 74 78 93
+Fax: +49 1803 622229 12790
+
+E-Mail: team@railslove.com
+
+Inhaltlich Verantwortliche gemäß TMG und § 55 Abs. 2 RStV: Michael Bumann, Jan Kus und Tim Schneider (Anschrift wie oben)
+
+Haftungshinweis: Trotz sorgfältiger inhaltlicher Kontrolle übernehmen wir keine Haftung für die Inhalte externer Links. Für den Inhalt der verlinkten Seiten sind ausschließlich deren Betreiber verantwortlich.

posts/2012-03-28-smacss-and-sass-the-future-of-stylesheets.markdown

@@ -1,30 +1,29 @@
----
-title: SMACSS and SASS - The future of stylesheets
-slug: smacss-and-sass-the-future-of-stylesheets
-author: jakob_hilden
-featured_image: http://smacss.com/img/book-covers.png
-published: true
-author_name: jakob
-author_email: jakob@railslove.com
-wordpress_id: 1318
-wordpress_url: http://blog.railslove.com/?p=1318
-published_at: 2012-03-28 18:15:20.000000000 +02:00
-categories:
-- railslove
-- rails
-- oss
-- css
-- sass
-tags:
-  keyword:
-  - smacss
-  - sass
-  - css
-  - stylesheets
-  - frontend
-  - modular
-  - conventions
----
+---
+title: SMACSS and SASS - The future of stylesheets
+slug: smacss-and-sass-the-future-of-stylesheets
+author: jakob_hilden
+published: true
+author_name: jakob
+author_email: jakob@railslove.com
+wordpress_id: 1318
+wordpress_url: http://blog.railslove.com/?p=1318
+published_at: 2012-03-28 18:15:20.000000000 +02:00
+categories:
+- railslove
+- rails
+- oss
+- css
+- sass
+tags:
+  keyword:
+  - smacss
+  - sass
+  - css
+  - stylesheets
+  - frontend
+  - modular
+  - conventions
+---
 I just had the the pleasure of attending the <a href="http://smacss.com/">SMACSS</a> workshop in Essen by Jonathan Snook (<a href="https://twitter.com/#!/snookca">@snookca</a>) and wanted to share my impression of the "SMACSS approach" to CSS and some considerations on using it together with <a href="http://sass-lang.com/">SASS</a>.
 <h2><strong>Overview: The philosophy behind SMACSS
 </strong></h2>
@@ -54,67 +53,49 @@ Secondly, the SMACSS approach was born out of experiences building Yahoo Mail an
 <h3><strong>Themes</strong></h3>
 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. <code>$themable-border-color</code>), instead of having to apply special classes to all the themable elements (<code>.theme-border</code>).  Here at Railslove we just had to create a new theme (basically a re-branding with different colors) on short notice for our client <a href="http://9flats.com">9flats.com</a> 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".
 <h3><strong>Submodules</strong></h3>
-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. <code>.dialog-wide</code> is a submodule of <code>.dialog</code>.  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) <a href="http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend">@extend</a> feature and you would simply do it this way:
-
-~~~css
-.dialog
+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. <code>.dialog-wide</code> is a submodule of <code>.dialog</code>.  While in traditional SMACSS you would need to apply both classes to your element (<code><div class="dialog dialog-weide" ></code>), using SASS you have the perfect use case for the (underutilized) <a href="http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#extend">@extend</a> feature and you would simply do it this way:
+<pre><code>.dialog
   width: 300px
   color: blue
 
 .dialog-wide
   @extend .dialog
-  width: 600px
-~~~
-
+  width: 600px</code></pre>
 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.
 <h3><strong>Module component syntax</strong></h3>
 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:
-
-~~~css
-.dialog
+<pre><code>.dialog
   width: 500px
 
 .dialog-header
   font-weight: bold
 
 .dialog-body
-  font-size: 13px
-~~~
-
+  font-size: 13px</code></pre>
 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:
-
-~~~css
-.dialog
+<pre><code>.dialog
   width: 500px
   .header
     font-weight: bold
   .body
-    font-size: 13px
-~~~
-
+    font-size: 13px</code></pre>
 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 <strong>keep the component number and nesting depth of your module to a minimum</strong>.  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 <a href="http://compass-style.org/help/tutorials/best_practices/">best practice</a> 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 <strong>loose</strong> a lot of <strong>clarity</strong> in the markup, because now it's not obvious anymore to which module a component class such as <code>.header</code> belongs to.  One idea to alleviate this problem could be to have a more obvious naming convention for module selectors (e.g. <code>.<strong>module</strong>-dialog</code>), 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 <strong>CSS performance</strong> 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 [<a href="http://calendar.perfplanet.com/2011/css-selector-performance-has-changed-for-the-better/">1</a>, <a href="http://bindle.me/blog/index.php/493/is-scss-killing-your-sites-performance">2</a>, <a href="http://www.thebrightlines.com/2010/07/28/css-performance-who-cares/">3</a>, <a href="http://www.stevesouders.com/blog/2009/03/10/performance-impact-of-css-selectors/">4</a>] 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:
-
-~~~css
-.dialog
+<pre><code>.dialog
   width: 500px
   .dialog-header
     font-weight: bold
   .dialog-body
-    font-size: 13px
-~~~
-
+    font-size: 13px</code></pre>
 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?
 
 <strong>File structure</strong>
 
 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
+<pre><code>+ applications.sass                  // @imports
 + base/
 |    _settings.css.sass              // SASS config variables
 |    _reset.css.sass
@@ -126,14 +107,12 @@ SMACSS already includes quite sensible naming conventions for selectors, but com
 |    _settings.css.sass              // SASS layout/grid variables
 |    _containers.css.sass
 + modules/
-+ non-modular/
-~~~
-
++ non-modular/</code></pre>
 I guess there is nothing too surprising in there.  The only thing that I would add is the folder/area for <strong>non-modular</strong> 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 <a href="https://github.com/pengwynn/dotfiles/blob/master/sass/sass.zsh">shell script</a> by Wynn Netherland to create a (much simpler) SMACSS folder structure for SASS, maybe this could be extended for further integration between the two.
 <h3>Submodule vs. component syntax</h3>
 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 <code>.navigation-header</code>, this could either be a <strong>submodule</strong> of the <code>.navigation</code> module (submoduled for the header context), or it could be a <strong>component</strong> of the <code>.navigation</code> 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 <code>--</code> vs. one <code>-</code> dashes, e.g. <code>.navigation--header</code> (I think for the component) vs. <code>.navigation-header</code> (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.
 <h2>tl;dr</h2>
 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.
+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.

posts/2012-04-09-meetrailslove-this-week.markdown

@@ -2,7 +2,6 @@
 title: ! '#meetrailslove this week'
 slug: meetrailslove-this-week
 author: jan_kus
-featured_image: http://blog.railslove.com/wp-content/uploads/2012/05/Bildschirmfoto-2012-05-21-um-13.04.43.png
 published: true
 author_name: Jan
 author_email: jan@railslove.com
@@ -20,10 +19,10 @@ tags:
   - meetrailslove
   - usergroups
 ---
-Hi Everybody,
-this week you can meet the Railslove-Crew at the following events (sorry for the germany description):
-
-<ul>
-<li><strong>Cologne.js User Group:</strong> Am Dienstag trifft sich wieder die Cologne.js UserGroup im Coworking Cologne Space Gasmotorenfabrik. Es werden wieder verschiedene Talks rund um das Thema Javascript, Backbone, Node.js behandelt. Los gehts am 10.04.2012 um 19:00 im Coworking Cologne Space Gasmotorenfabrik in der Deutz-Mülheimerstr. 129, 51063 Köln. Mehr Infos unter: <a href="http://colognejs.de/">http://colognejs.de/</a>.</li>
-<li><strong>Limited WIP Society Cologne:</strong> Am Mittwoch Abend trifft sich die Limited WIP Society Cologne - oder kurz - Kanban User Group. Hier treffen sich die Leute aus Köln und Umgebung, die sich für Lean und Kanban im Bereich der Wissensarbeit interessieren. Los geht es am 11.04.2012 um 19:00 Uhr  im Coworking Cologne Space Gasmotorenfabrik in der Deutz-Mülheimerstr. 129, 51063 Köln. Mehr Infos unter: <a href="http://lwscologne.wordpress.com/">http://lwscologne.wordpress.com/</a>.</li>		
-<li><strong>Echtzeit Köln III:</strong> Am Donnerstag findet die dritte Echtzeit Köln statt. Es ist ein exklusives Netzwerktreffen im Rheinland. Die Veranstaltung richtet sich an Gründer, Business Angels und Investoren. Zugang ist nur über persönliche Einladung durch das Team von deutsche-startups.de - bewerben kann man sich per E-Mail (Betreff: Echtzeit Köln) an echtzeit@deutsche-startups.de.</li>		
+Hi Everybody,
+this week you can meet the Railslove-Crew at the following events (sorry for the germany description):
+
+<ul>
+<li><strong>Cologne.js User Group:</strong> Am Dienstag trifft sich wieder die Cologne.js UserGroup im Coworking Cologne Space Gasmotorenfabrik. Es werden wieder verschiedene Talks rund um das Thema Javascript, Backbone, Node.js behandelt. Los gehts am 10.04.2012 um 19:00 im Coworking Cologne Space Gasmotorenfabrik in der Deutz-Mülheimerstr. 129, 51063 Köln. Mehr Infos unter: <a href="http://colognejs.de/">http://colognejs.de/</a>.</li>
+<li><strong>Limited WIP Society Cologne:</strong> Am Mittwoch Abend trifft sich die Limited WIP Society Cologne - oder kurz - Kanban User Group. Hier treffen sich die Leute aus Köln und Umgebung, die sich für Lean und Kanban im Bereich der Wissensarbeit interessieren. Los geht es am 11.04.2012 um 19:00 Uhr  im Coworking Cologne Space Gasmotorenfabrik in der Deutz-Mülheimerstr. 129, 51063 Köln. Mehr Infos unter: <a href="http://lwscologne.wordpress.com/">http://lwscologne.wordpress.com/</a>.</li>		
+<li><strong>Echtzeit Köln III:</strong> Am Donnerstag findet die dritte Echtzeit Köln statt. Es ist ein exklusives Netzwerktreffen im Rheinland. Die Veranstaltung richtet sich an Gründer, Business Angels und Investoren. Zugang ist nur über persönliche Einladung durch das Team von deutsche-startups.de - bewerben kann man sich per E-Mail (Betreff: Echtzeit Köln) an echtzeit@deutsche-startups.de.</li>		

posts/2012-04-19-getting-started-with-tech-at-rails-girls-berlin.markdown

@@ -0,0 +1,32 @@
+---
+title: Getting started with tech at Rails Girls Berlin
+slug: getting-started-with-tech-at-rails-girls-berlin
+author: tatjana_lajendacker
+published: true
+author_name: tatjana
+author_email: tatjana@railslove.com
+author_url: http://www.railslove.com
+wordpress_id: 1449
+wordpress_url: http://blog.railslove.com/?p=1449
+published_at: 2012-04-19 15:32:39.000000000 +02:00
+categories:
+- railslove
+---
+On 13th & 14th of April the Railslove Girls attended <a title="Railsgirls" href="http://railsgirls.com/berlin">Rails Girls Berlin</a>.Developer Lena was one of the coaches, Liane (Designer) and I attendees, and Railslove was one of the sponsors.
+
+<a href="http://blog.railslove.com/wp-content/uploads/2012/04/IMG_05441.jpg"><img class="size-medium wp-image-1454 alignleft" title="Rails Girls Installation Party" src="http://blog.railslove.com/wp-content/uploads/2012/04/IMG_05441-e1334841464745-224x300.jpg" alt="" width="224" height="300" /></a>
+
+It was a really, really great event and we had an awesome time. We especially enjoyed the vibrant and inspiring atmosphere and were amazed by all the energy and creativity sparked by 100 hackerettes ^_^ The feedback on Twitter was absolutely amazing!
+
+During the day the coaches helped groups of 4-6 women with different backgrounds to build a basic Ruby on Rails application - CRUD for one resource with photo upload. In between we went through a Ruby tutorial (<a title="ruby tutorial" href="http://tryruby.org/levels/1/challenges/0">http://tryruby.org</a>) and heard some great lightning talks.
+
+The coaches made sure we understood everything, and even if we‘re still in the early stages of learning Rails, Rails Girls was a very good and interesting way to gain first impressions of Rails!
+
+In just one day, the Rails Girls crew covered a wide range of topics - we learned lots about Ruby internals like variables, methods, strings, database tables, models, gems and so on.
+Besides that we also picked up some basic Unix skills, like how to change the directory and restart the server, what commands belong into the terminal and what into the text editor. And last but not least we learned about web technology in general and browsers.
+
+One of the many great outcomes of this event is that there are already plans for a follow-up workshop in Berlin next Saturday from 12-18:00 at the co.up coworking space (<a title="co up space" href="http://co-up.de/">http://co-up.de</a>), where participants can go through the tutorial again, refine and extend their code, maybe introduce some "comments" to the "ideas" ... Lena will be there again and more coaches will join!
+
+<a href="http://blog.railslove.com/wp-content/uploads/2012/04/IMG_05781.jpg"><img class="size-medium wp-image-1458 alignright" title="Rails Girls Cookbook" src="http://blog.railslove.com/wp-content/uploads/2012/04/IMG_05781-300x224.jpg" alt="Rails Girls Cookbook" width="300" height="224" style="float:right; margin-left:10px" /></a>We truly felt lucky to have such a talented and enthusiastic crowd of people with us at Rails Girls and hope many of us will continue working with Rails in the future. I‘m pretty sure Liane and I will... and maybe some day soon we‘ll build something cool! We‘ll let you know :)
+
+Lots of thanks to the fantastic and patient coaches & organisers of this fantastic weekend!