A blog about design, code and some other stuff

CSS was meant to style academic documents and simple sites (eg. wiki, blogs) where the cascade and descendant selectors makes a lot of sense. Unfortunately many sites we build nowadays are way more complex than that, and what used to work on simple projects doesn’t scale very well. We need to find smarter ways to code CSS to avoid the common issues and re-think the way we do our work. We should learn from the experience of other devs working in different domains, and apply into our own domain. Things like separation of concerns, modularity, encapsulation, DRY can (and should) be applied to large scale CSS projects as well. The main problem is that most people who are good at CSS doesn’t necessarily have a Computer Science background, most of them started as designers and learned CSS by themselves (that was my case…). That’s the main reason why I’m writing this post.

I won’t get into too much details/examples but will try to explain briefly each concept. Some of the SOLID principles are open to multiple interpretations on the CSS context - since we are shoehorning the concepts - that’s one of the reasons why I decided to not give detailed examples. I also think we should understand the idea and not be tied to a specific implementation.

Read more…

I started using node.js to write build scripts since last year and even wrote a post about it before. The main reason why I decided to write my build scripts in plain JS is because I want them to be flexible and easy to edit. (Use the language you and your team are familiar with).

On this post I will try to cover some issues and the main reason why I’m not using a tool like grunt, buildr.npm, smoosh and gear on my projects. I’ll focus on Grunt since it is the most popular node.js build tool out there but the issues are present on other build tools as well (written in JS or not).

A couple days ago I sent a few tweets about it:

somehow I feel that @gruntjs is making the same mistakes as Ant. I would rather call JS methods instead of setting config options…

— Miller Medeiros (@millermedeiros) August 1, 2012

it would also make more sense to just run `node grunt mytask` instead of global install, would work better on windows. /cc @gruntjs

— Miller Medeiros (@millermedeiros) August 1, 2012

now I had a “crazy” idea for a project. A node.js adapter for Ant so you can call any task as a JS method passing JSON configs. #notdoingit

— Miller Medeiros (@millermedeiros) August 1, 2012

TL;DR; Build scripts should be real scripts and not configuration files.

Read more…

This post is about a very simple thing that I’ve been doing since I started to code (by coincidence) and that I feel that increases a lot the readability and organization of my code. Some people may not agree with it but for me it makes total sense and was also documented by some experienced developers like Uncle Bob on his great book Clean Code. I tend to think that a single approach may not be the best one for everybody - since every person thinks on a different way - but I’m pretty confident that this advise will be good to a lot of people and that it will increase the overall quality of the code.

The rule is simple, split larger functions/classes into smaller specialized ones, period. It will not only increase the readability but it will also make the code more reusable since it will be easier to override the default behavior if needed (especially if extending a class or reusing a 3rd party lib). I will try to explain how and give a basic example.

Read more…

(not sure if the pirate image + caption was created by Zeh Fernando, he sent it to me a couple years ago, forgot to ask him…)

Another polemic subject and something that I’ve been delaying for a while, I’ll try to explain how I got to my conclusions and I’m sure a lot of people won’t agree until they experience the same problem or realize how often it may happen on a real project and specially if it does happen with a code you don’t “own” and/or can’t change without compromising future updates… The advice is mostly about JavaScript (since it’s what I’ve been coding more lately and where I think the issue is bigger) but it also fits other languages.

Not so long ago I had an opposite opinion about this subject - I would always set everything to private and only changed to protected/public if needed - try to understand what made me change my opinion and pay attention every time you find yourself “tied” or doing lots of hacks just because you can’t monkey-patch a simple function/variable.

Read more…

This post is very polemic, I thought a lot before publishing it, please try to be open-minded and read the whole thing before commenting, it is not supposed to become a flame war. Please read the about page to understand the objective of this blog and the way I think about it.

I’ve been considering to use a CSS pre-processor like SASS, LESS, Stylus, etc, for a very long time. Every time someone asked me if I was using any of these tools/languages I would say that I’m kinda used to my current workflow and I don’t really see a reason for changing it since the problems those languages solves are not really the problems I’m having with CSS. Then yesterday I read two blog posts which made me reconsider my point of view so I decided to spend some time today studying the alternatives (once again) and porting some code to check the output and if the languages would really help to keep my code more organized/maintainable and/or if it would make the development process easier (also if they evolved on the past few years).

Read more…