Sponsors are still welcome to support us and help offering an even more exciting Coworking Cup 2012. Don’t hesitate to contact us!

Sign up and challenge your luck!

Place your forecasts and challenge your luck!

Website: http://www.cowocup.com
Facebook: http://www.facebook.com/CoworkingCup
Twitter: https://twitter.com/#!/CoworkingCup

Thanks for everyone who has joined! Hope to see you all next time again!
Now, here is a nice hackathon video and loads of pictures can be found on the railslove flickr account and at medien.nrw

Behold, Pinkify! It’s in an early stage, but when you have a look at available options, you’ll get the idea what you can do.

A more detailed documentation is yet to come.

As an appreciation gift for all the bronies Mike made this pony. She’s called Heart Charmer, and refers to both our heart and how charming all of us are. ;)

Enjoy the pony after the break.

– EDIT from Mike:
Wow, you guys are crazy!

We’ve been featured on Equestria Daily!

Animated Pinkie Pie GIF is made by ~fluttershylover:


(click for DeviantArt page)

— EDIT 2
What the buck, videos, music.

Rails Loves Pinkie by VinylAndOctavia

— EDIT 3
Featured on My Little Brony

In 2011, the first European Pirate Summit took place. EPS is a meetup for innovators and adventurers. It’s a conference about people that have stories to tell. EPS is about stealing gold and taking over the world. It’s about pirates like The Horrid Slave and his crew! Best have a look at this short video from last year’s event:

Are you a pirate?

If you want to join the crew… learn to speak like a pirate, read this article, prepare presentations like this and listen to this song over and over again. The last step is to send out this application. But what are real pirates doing?

They are drinking rum and hacking sites like this one: http://railslove.com/arrr!

And because Railslove loves the EPS our Railslove DJ will play this song over and over again and we will keep this site until some other pirates are hijacking our website. Try it… you lose! ARRR!

Say Ahoy! to EPS in September 2012

This year about 500 EPS pirates are taking over Cologne on 10-11th of September.

What do you can expect this year? First of all… awesome captains like Fred Oliveira of 500 startups,
Andreas Ehn, 1st CTO of Spotify and current CTO of Wrapp, and Frank Thelen of doo. But stay tuned… the message in the bottle is still on its way to some other seadogs!

Like last year there will be a pitch competition (apply now!).

Young pirates are the future – EPS Scholarship

As we know – we need more pirates. And young pirates are learning quick. If your dream is taking over the startup world one day, best start learning as early as possible! So together with EPS we’re searching young talent to bring fresh ideas aboard. We’ll teach the all the required skills to craft their own businesses one day – pirate style! Railslove will be helping out with coding workshops for kids this year – check out the Railslove University page for more details soon. We’ve already successfully organised Ruby-on-Rails-from-Scratch courses in the past for students. We believe that kids are the future, so let’s provide them all the tools and knowledge they need! More dojos, more pirate training camps, more kick-ass teaching, more mayhem, more ARRRRRRRR – ARRRRRR!
Imagine a world of 18-year-young captains setting sails for exciting new waters!

Godspeed!

• Adcloud TechTalk (25.04.): This Wednesday AdCloud are hosting their first TechTalk. The first talk will be about Chaplin – a JavaScript Application Architecture with Backbone.js. For more information check out http://dev.adcloud.com/blog/2012/04/16/chaplin/. This is a really good opportunity for anyone interested in frontend technology to learn about one of the most exciting new JavaScript projects. More information on Chaplin can be found on http://9elements.com/io/
• Kölsch.rb (25.04.): Like every month the Cologne Ruby User Group meets for some very interesting discussions. E.g. AvocadoDB and embedded Ruby with “mruby”, “Ruby on R with RSRuby” or some testing small talk with Ede. This week we’re meeting at Coworking Cologne Gasmotorenfabrik. If you have any point of contact with Ruby development this event should be required for you. For more information check out http://hcking.de/events/40/single_events/570.
• ADVANCE HACKATHON (27.04.-29.04.): A meetup for hackers and thinkers – imagine you are sitting together with the most talented web & app developers and designers for kicking off your own or others’ projects, refine or complete code collaboratively, or just experiment with others. This is the purpose of the hackathon and if you have any interest in the web at all you will find no better place to meet interesting people and see a lot of cool projects. For more information check out http://hackathon.advance-conference.com/en/. Unfortunately this is event is already sold out.
• Webmontag (07.05.): Webmonday is an informal, non-commercial, and completely community-driven event that aims to connect the people who are shaping the future of the internet. As usual we’re discussing interesting web driven topics, hacking ideas etc. Check out: http://www.webmontag.de/location/koeln/2012-05-07
• UX-CGN (15.05.): UX-CGN is a new format discussing different topics about user experience. If you’re interested in frontend, frontend development and usability, visit this user group and meet people that speak your language. http://uxcgn.org/
• SIGINT (18.05.-20.05.): SIGINT is a conference on discourses in the digital age. It addresses socio-political demands for participation and change, utopias, hacktivism, as well as the creative breaking of norms. For more information check out http://sigint.ccc.de/Main_Page.
• Clash of Realities Conference! – 4th international Computer Game Conference (23.05.- 25.05.): The international game developer scene comes to Cologne to meet for a three day conference organized by the Department of Media Studies and Media Education and the Cologne Game Lab in cooperation with Electronic Arts. If you wanna get into the world of game development this is your chance. For more information check out http://www.clashofrealities.org/.
• DevHouseFriday Chillout (25.05.): we’ve moved the meetup because of the ADVANCE HACKATHON. The next DevHouse Friday is happening @ Pixum – “Wir machen den DevHouse Friday Chillout zum Erlebnis” and is a great chance go meet a lot of interesting people around the Cologne web scene. For more information check out http://devhousefriday.org/networks/events/show_event.52535.
• Bastelnachmittag Every Friday: the Dingfabrik meets in their rooms for Bastelnachmittag. Just play around with your arduino or do some origami – everyone can have some fun! Date: Friday 4th of May. For more information check out: http://hcking.de/events/84-dingfabrik-bastelnachmittag

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!

If you wanna to see us coding – just come over to our office or watch
our Hackathon Github Wiki Page, our Twitter Stream (official hashtag
#rlhck2012) or just see what‘s going on on Facebook:
http://www.facebook.com/Railslove

For the Advance Hackathon, developers from all over North
Rhine-Westphalia (NRW) will meet from Friday to Sunday at our office, the
Gasmotorenfabrik Deutz! We’ll get started with a kick-off meeting and
drinks on Friday evening. During the following two days, groups of 8-10
developers will hack on exciting projects and fight for cool awards!
If you want to know more about Advance Hackathon check out the
following links:
Twitter: https://www.twitter.com/advanceconf Hashtag  #ADVANCEhack and
#ah12
Facebook:  https://www.facebook.com/advanceconf
Google+:  https://plus.google.com/114507277756579411949
Starting on April 27th: Flickr, Hashtag #ADVANCEhack
http://www.flickr.com/search/?w=all&q=%23ADVANCEhack&m=text

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 (http://tryruby.org) 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 (http://co-up.de), 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!

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!

• Cologne.js User Group: 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: http://colognejs.de/.
• Limited WIP Society Cologne: 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: http://lwscologne.wordpress.com/.
• Echtzeit Köln III: 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.
]]> http://blog.railslove.com/2012/04/09/meetrailslove-this-week/feed/ 0 http://blog.railslove.com/2012/04/09/cologne-startups-open-hours-first-results/ http://blog.railslove.com/2012/04/09/cologne-startups-open-hours-first-results/#comments Mon, 09 Apr 2012 13:24:06 +0000 Jan http://blog.railslove.com/?p=1427 I would like to share the first results of our Cologne Startup Open Hours last friday. After a 3 hour session at the Solution Space we’ve gathered some nice topics. Join our FB Group and feel free to edit this document



]]> http://blog.railslove.com/2012/04/09/cologne-startups-open-hours-first-results/feed/ 0 http://blog.railslove.com/2012/04/02/cologne-startups-open-hours-coaching-session/ http://blog.railslove.com/2012/04/02/cologne-startups-open-hours-coaching-session/#comments Mon, 02 Apr 2012 19:52:59 +0000 Jan http://blog.railslove.com/?p=1421 Need advice on your business plan, marketing strategy, or funding approach? Come and join Thomas Grota for our first exclusive mentoring / coaching session for Cologne Startups!

Thomas is a Senior Investment Manager at T-Ventures and Member of the respective Boards of MyTaxi, 6Wunderkinder, apprupt and others. He is Mentor at Seedcamp. Thomas has more than 15 years of experience as an advisor, manager, and investor as well as being a frequent speaker at conferences across the startup and tech scene.

LinkedIn Profile: http://de.linkedin.com/in/thomasgrota
Crunchbase: http://www.crunchbase.com/person/thomas-grota
Twitter: @thomasgr

Many thanks to Thomas for taking the time out of his busy schedule to pledge his support for this first of its kind coaching session!

** Please prepare specific questions to make this session as efficient and valuable as possible! **

Solution space am Brüsseler Platz
Brüsseler Platz 26, 50674 Köln, Germany

(via https://www.facebook.com/events/130180813773807/)

]]> http://blog.railslove.com/2012/04/02/cologne-startups-open-hours-coaching-session/feed/ 0 http://blog.railslove.com/2012/03/30/meetrailslove/ http://blog.railslove.com/2012/03/30/meetrailslove/#comments Fri, 30 Mar 2012 15:07:04 +0000 Jan http://blog.railslove.com/?p=1412 Hey ho!

Here’s a short overview of events happening in April around Cologne. If you want meet us just pop by or simply check out #meetrailslove on Twitter to hang out with us whenever you want!

• Bastelnachmittag bei der Dingfabrik: 06.04.2012 um 19:00
• Cologne.js im Coworking Cologne: 10.04.2012 um 19:00
• Limited WIP Society Cologne – Kanban Usergroup Köln (Köln): 11.04.2012 um 19:00
• Echtzeit Köln: 12.04.2012
• Bürogolf – “Schönes Spiel” bei AZIMUT: 17.04.2012
• Bastelnachmittag bei der Dingfabrik: 13.04.2012 um 19:00
• Cologne Clojure User Group: 19.04.2012
• Kölsch.rb (Ruby UserGroup) im Coworking Cologne: 25.04.2012
• Advance Hackathon im Coworking Cologne: 27.04.-29.04.

If you’re missing some events just have a look at hcking.de – there are lots of others.

We’ll also be at Railsberry in Krakow.

We’re looking forward to meeting you soon!

]]> http://blog.railslove.com/2012/03/30/meetrailslove/feed/ 0 http://blog.railslove.com/2012/03/30/das-burogolfen-geht-in-die-nachste-runde/ http://blog.railslove.com/2012/03/30/das-burogolfen-geht-in-die-nachste-runde/#comments Fri, 30 Mar 2012 13:08:25 +0000 Jan http://blog.railslove.com/?p=1399 “Schönes Spiel” bei AZIMUT am 17.04.2012

Da für einige von Euch die Teilnahme für das Bürogolfen im Railslove-Office/Coworking Cologne beim letzten mal nicht geklappt hat gibt es jetzt eine neue Gelegenheit das Bürogolfen für sich zu entdecken. Wie auch letztes mal, treffen sich Unternehmer, Gründer und Denker aus allen Branchen um ihr Handicap zu verschlechtern. Denn unterm Tisch liegend, auf der Treppe und über Türschwellen golft jeder gleich schlecht, macht aber nix, denn darum geht’s ja auch nur im weiteren Sinne. Ein netter Networking-Abend in entspannter Atmosphäre: denn auf dem Golfplatz duzt man sich ja schließlich.. ;-)

Dieses mal findet das Bürogolfen in den Räumlichkeiten des AZIMUT Hotels Cologne City Center statt.

Wenn Ihr Interesse habt dabei zu sein, schreibt mir bis zum 10.4. eine E-Mail an: jan@railslove.com. Ich bitte um Verständnis, dass nicht alle Anmeldungen berücksichtigt werden können.

Ich würde mich freuen Euch zu sehen!



]]> http://blog.railslove.com/2012/03/30/das-burogolfen-geht-in-die-nachste-runde/feed/ 1 http://blog.railslove.com/2012/03/28/smacss-and-sass-the-future-of-stylesheets/ http://blog.railslove.com/2012/03/28/smacss-and-sass-the-future-of-stylesheets/#comments Wed, 28 Mar 2012 16:15:20 +0000 jakob http://blog.railslove.com/?p=1318 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.

]]> http://blog.railslove.com/2012/03/28/smacss-and-sass-the-future-of-stylesheets/feed/ 14