Nice to meet you. I'm Daniel, passionate learner and maker.

Day in the Life at Dropbox: Rasmus Andersson

July 14, 2013 - permalink

Rasmus Andersson:

I wish I knew that being a designer is not really a ‘thing.’ In the late 1990s when I had my first job as a designer and knew that this was something I enjoyed doing, I had this sense that there was a designer profile. You know, that a “designer” has a certain kind of computer and likes certain kinds of typefaces. It turns out that typefaces and computers have nothing to do with design, as they are just tools and subject to trends and fashion. I thought that I needed to go to expensive graphic design schools to “become” a designer. If I only knew that I already was a designer and that I had been since I was a little kid, my life would probably look a little bit different. I should just have focused on building the things I enjoyed building.

Everyone of us is in some way already a designer. Making things look nice isn't everything which defines a designer. Designer are creators. Creator of that useful app on your smartphone, creator of that everyday item on your desk, creator of that new haircut on the top of your head, creator of that three little words to say someone how you feel, creator of that wake/sleep cycle called life. You are a creator. You are a designer.

Inside GitHub #1: Freedom

July 11, 2013 - permalink

GitHub started a web series called Inside GitHub where they talk about work philosophy, company culture, and product development. Awesomeness.

The very latest new new way to do "clearfix"

July 04, 2013 - programming - permalink

Thierry Koblentz:

.cf:after {
  content:"";
  display:table;
  clear:both;
}

To be honest, I have never used the clearfix hack in a production app before. I'm one of those guys who until today used the old way of applying a <div class="clear"></div> and a css class .clear { clear: both; } at the end of floated elements to clear them out. I tried to apply some other new ways of clearing floated elements before, but somehow I always got stuck somewhere and it didn't really worked out for me.

Today I think I found my resolution. The above code snipped seems to be the latest hipster way of doing it. So far it has also worked out for me and with the use of some Sass @extend magic I might not even need to add additional markup to my HTML/Sass files in the future. Cool.

My Design Philosophy

July 01, 2013 - permalink

Victor Erixon:

In the early stages of my career, I always felt like something was missing in my designs––maybe a colorful call to action button or perhaps an extra needed feature. But during my later days, I’ve come to realize that maybe it is the way I was raised. I’ve always loved minimalism, always believed in that less is more and that you should always ‘kill your darlings’.

Never settle for ‘lagom’.

Friday is Webday

June 28, 2013 - friday is webday - permalink

Get free access to the Friday is Webday link collection and receive a weekly update on every friday

Hello world. Today I want to introduce you to one of my latest experiments called: Friday is Webday.

You might think:

What the heck is Friday is Webday?

The answer is: I'm not sure yet.

The current idea behind Friday is Webday is to provide my lovely web geek friends with useful proteins like must read blog articles, innovative JS libraries they should check out, web ninjas they should follow and other webby gooides they might find useful.

To bring those informations into the brains of my fellow padawans I'm going to use the force to magically fill spam your inbox every friday with an good ol' newsletter of mine.

Jokes onto the bike (I actually know someone who says that when he wants to get serious)

I'm going to create a weekly newsletter which is filled with web links I discovered (and other stuff I might think a web designer/developer finds use in it) through the week. You can subscribe here.

If you now any article, inspirational quotes or anything else you think could be useful for this newsletter hit me on twitter or write me an email and I will give it a look and mention you in the newsletter.

So now that everything is clear, lets do this!

LET'S DO THIS GIF

(If you laughed at that gif don't forget to subscribe ;)

Why I prefer Sass over SCSS

June 21, 2013 - programming - permalink

First, I want to point out that this article is not a rage article about the SCSS syntax. I don't mind if you use the Sass or the SCSS syntax to achieve your daily goals. Anything that suits you, suits me. Damn, I'm even glad if you use Sass in general instead of writing old plain bad ass CSS code. I've met a lot people who don't even now about CSS pre-processors yet and I think that is a shame, because they give you a major productivity boost. If you are one of those people, stop reading now and follow this link here. After that, you can come back and read on if you want.

Recently, I often read about comments or blog post from people who prefer the SCSS syntax over the Sass syntax. Most of the time their reasons are that valid CSS is valid SCSS and you can simply copy and paste third party code into your SCSS file and its just going to work. Well that is true and makes the transition from plain CSS to SCSS most likely very easy. But I'm not a big fan of copy and paste code so this not an attribute I care about.

But Daniel, what do you do when you want to use third party extensions in your projects?

Well, I admit, I use SCSS. But only for that use case. I put it into my project, rename it to _plugin.css.scss or _plugin.scss and import it into my base stylesheet.

But when it comes down to writing Sass or SCSS code, Sass wins for me. And this post is going to show you why I personally prefer Sass over SCSS.

#1 - More readable syntax

This is probably the number one reason why most of the people (including me) prefer Sass over SCSS. All you have to care about in Sass is indention, you don't have to care about clumsy semicolons or curly braces which are going to bloat up your stylesheets like they would in SCSS.

Many could (and probably will) argue that SCSS will support you with writing better code because you actually see it when you have nested your code to deeply based on the curly braces in SCSS. Well if you're new to writing Sass code this is probably a good argument but after you got the hang out of it I don't think you really need that help any longer.

Another plus for me is, that the Sass syntax is more maintainable because of its easy to read syntax. But I'm not going to take the maintenance argument any further, because the syntax alone isn't the key to keep your stylesheets maintainable. More about that topic in the future.

#2 - Less code

Yes, I'm a lazy programmer. I don't like to repeat myself over and over again and writing stuff with a lot of characters when there is a way to write it with less. And this is the second reason I prefer Sass over SCSS. Lets take a look:

// SCSS
@include border-radius(10px);
// Sass
+border-radius(10px)

Okay, maybe someone can argue that this is basically the only thing where Sass has a shorter syntax. But again, don't forget about the semicolons and curly braces (the following example was taken from the sass-lang.com website):

// SCSS
table.hl {
  margin: 2em 0;
  td.ln {
    text-align: right;
  }
}

li {
  font: {
    family: serif;
    weight: bold;
    size: 1.2em;
  }
}
// Sass
table.hl
  margin: 2em 0
  td.ln
    text-align: right

li
  font:
    family: serif
    weight: bold
    size: 1.2em

And I don't know nothing about you, but for me, this means I'm faster in writing CSS code, faster in finding and replacing existing CSS code, faster in fixing CSS bugs, and so on. Which means I can go home earlier than others and do stuff I care more about than a languages syntax.

#3 - Because I want to

Let me get this straight. Those are the reasons why I prefer Sass over SCSS. There are a lot of reasons why someone can and should use SCSS and from my experience it strongly depends on how you work and the project you're working on. I try to get my work done as fast as possible and I personally hate curly braces and semicolons (I also dislike Java and love Ruby). But the major productivity boost doesn't come from the Sass syntax itself. They come from the pre-processor features themselves and are covered in both syntaxes. But when you're a productivity freak like me, every second matters. This is probably also a reason why I mostly write Rails applications and use vim doing it. For me the Sass syntax just feels more like how writing stylesheets should be.

So my conclusion to this rather short article is probably that you should use both the Sass and the SCSS syntax. But in the end its just a question of taste and what you personally want to use (at least when nobody tells you what you have to use for a certain project).

This article are just my two cents to the discussion. Thanks for reading. If you want to take this any further hit me on Twitter: @danielpuglisi

Thanks Daniel

May 24, 2013 - permalink

This is a thank you post for my namesake Daniel Keller.

Thanks for arranging that I got invited to dribbble and another big thank you for creating that awesome logo for me :)

To everyone who reads this, check him out. To everyone who needs a new logo / identity design - hire him. One of the best logo design artists I know.

Migrate your Blog from Jekyll to Rails

April 15, 2013 - programming, rails - permalink

I've used Jekyll for almost a year now and it did good services to me.

Although, I decided it is time to let go from my beloved Jekyll application and move on to a shiny new Rails 4.0 app. I always loved the simplicity of Jekyll and how I could control everything through git and my vim. But it was time for something new, something more flexible and dynamic.

Until this week I had written about 80 articles which were lying around in different category directories in my Jekyll repository. To migrate them all to the new Rails app, I've written a Rake Task which extracts the single values and keys from the YAML Front Matter section and the article content and saves everything to the custom post model in my application. The gist can be viewed here.

Feel free to reuse or revise the script to your own purpose. If you have any questions, hit me on Twitter.

Rails Girls: After The Event, How To Continue With Programming

April 07, 2013 - railsgirls - permalink

This blog post is now part of the official Rails Girls guides

First of all, thank you all for joining us at the Rails Girls Event in Basel. It was so much fun and I want to thank you all for being super motivated. You are awesome!

So unfortunately (!) the event is already over and I am writing this blog post to help you find the best way to keep going with learning on how to program!

There are 4 steps which I've come up with and I encourage you to really take them to your heart and do them.

Originally this talk was planned for the end of the event but you girls were so focused on coding that we just didn't want to interrupt you. :)

So here it goes:

1. Keep on Coding

Mastering a craft requires constant repeating and perseverance. This also applies to programming. I encourage you to repeat the Rails Girls tutorial which we did at the event and try to play around with it some more.

After that here are some free and paid resources which will help you to take things to the next level:

Courses

  • Rails for Zombies - A Rails Screencast which was created by Codeschool. Its free and Codeschool provides also a series of paid Ruby and Rails courses which are awesome. You should really try them!
  • Codecademy - The world isn't just created with rubiez. There are also plenty of other languages like HTML/CSS, JavaScript, Python and so on. Try them out.

Books

  • Rails Tutorial - A awesome book which has a free HTML version and a paid print version. The book provides you with a lot of great material which we couldn't cover at the Rails Girls workshop.

Screencasts & Videos

MOAR

If you have any other good resources, hit me so I can put them into the list.

2. Build something real

Build something real means you should try to create something which is actually needed in the end. The hardest part will be to find a real project. If you have no idea, try to think of something that really upsets you. Do you have to use something in your daily life that pisses you off? Write an application for it and try to solve that pain. This way you will be more motivated than by just following tutorials.

And don't forget to show your application to your friends and the world. Ask for feedback and keep on learning.

If you still have trouble finding something you can work on I have an idea for you: railsgirls.ch.

We could use a new Rails Girls Switzerland website and if you are interested you could fork our repository and build something better and new! :)

3. Get in touch

Its always easier when you have someone you can ask. With this in mind, go out and find someone who you can talk to. Now is the best time for it, because you just got to know a lot of like minded people which have more or less the same level as you. There are a lot of ways to communicate nowadays, e.g. host a local meetup group, use Google Talk, create Facebook Groups or write a good ol' letter :)

From my experience, knowing some people who have the same interests as you is one of the most important parts. Try to convince people, that programming is fun. If you have a brother or a sister, show them what you've learned. Or show it to your parents, children or friends. Just try to build a circle of people with the same interest in programming and technology.

Also try to find something like a mentor. Programming can be really intimidating sometimes, so it can help to know someone which has more experience and can help you with your problems. For example: ask someone of the Coaches who attended at the Event. You find a complete list of them here on Twitter.

If you don't have the time to host your own meetup group, thats ok. There are already a few groups which you can join:

  • Ruvetia - Ruvetia is a meetup (or drinkup) where we will come together every now and then and just socialize. This meetup is not about content, its about getting to know the people in the community. Every meetup is in a different city so check out the Ruvetia website from time to time where the next meetup will take place.
  • Railshöck - A Rails meetup in Zurich
  • Geneva Ruby Brigade - Ruby group based in Geneva

This list is incomplete, so if you know another meetup, contact me and I will add it to the list.

One of the girls at the event (thanks Helena!) had the great idea that we could put up a list with all the attendees, coaches and organizers.

Update: I created the list and its on Github, check it out here.

4. Have fun

Last but not least, have fun. If you don't enjoy programming it is probably not the right thing for you. But thats the same story for every profession or hobby. Not only for technology related topics. But if you just read this I think you are perfectly made for programming, otherwise you wouldn't be here in the first place ;)

So, if you liked the workshop and the event - you're in the right spot.

If you have any further questions, don't hesitate to ask. You can do this via Twitter or via Mail. The Codegestalt Team will be happy to try to help you and answer your questions. Just drop us a line on contact@codegestalt.com.

I also want to send out a big hug to Rodrigo and Magdalena and all the coaches and assistants. You guys rock and without you, the event would not have been the same! <3

Thats it, keep on coding and let's build the future!