A blog about design, code and some other stuff

I’ve been working on many different kinds of projects through the past years, some of them with a very short lifespan (3-6 months) and almost no maintenance after launch and others with constant updates and planned to last for many years, from facebook applications to mobile websites, microsites, intranets and large dotcoms… I committed a lot of mistakes and done a few things right as well. One thing that I’ve been realizing is that some things that are usually considered “bad practices” sometimes can be the most productive solutions and that the drawbacks from taking a “shortcut” may not exist if you do it with caution.

I’m a huge advocate of clean and maintainable code, I really believe that grouping things by context is usually the best approach – style should be stored on external stylesheets, JavaScript should be on external files as well and the HTML should only hold the markup and content… - But I also think that best practices exists for a reason and we can’t forget what kind of problems they solve and why they were created, following rules blindly is almost as bad as breaking them without a good reason.

I’m going to try to explain some cases where inline styles and using JavaScript to set styles can be the recommended approach. – To all the zealots out there, try to understand that each project have different goals and requirements and that what is often considered a bad practice can be a reasonable solution in some cases…
Read more…

Clear and descriptive names can increase a lot the readability and the understanding of a certain API or application, in some cases it can be a decisive factor on the success of a project.

I will share a few rules that I started following on the past years after reading many books and blogs about development, discussing with co-workers about it and mostly by experience. Most of the rules may seem dumb/obvious to a seasoned developer, but it is really impressive how many APIs from well-known libraries commit some huge mistakes and I think that a lot of people still don’t care about it as much as they should… I try to follow these rules as much as possible since I believe they contribute a lot for the quality and maintainability of my code but some people may not agree with my naming conventions and sometimes rules should be bent^[1] or even ignored, take it as an advice not as a something “set in stone”.

Read more…

Many programming languages and environments require a Main Class, Main function or Main file as an entry-point to the program, it’s where the execution starts and also usually where you have access to command arguments. JavaScript on the browser isn’t one of those environments tho, and I think it is one of the reasons why many applications become a real maintenance nightmare. I believe that the “Main File/Function/Class” approach can help a lot to increase extensibility/maintainability and favor a good structure even for languages that doesn’t require this practice.

Many back-end frameworks started to adopt this technique over the past years, most of them have some sort of URL redirect that points to a “index” file or a router that decides which actions should be executed and which files should be loaded instead of having a single file for each page or section. This kind of abstraction increases flexibility a lot since you can just keep adding new pages/sections/features without having to care about the code structure, it also reduce code duplication since you don’t need to create a new file for each new page…

Flash projects have a Main Class which is the entry-point for the application and also works as the root node where all the child elements are attached (similar to the body element of an HTML file) and it helps you keep the code flow organized since you are sure that your Main Class constructor is executed before any other code, programs get easier to understand since it follows a logic order.
Read more…

I know this subject is controversial but I have to say it…

I started using JavaDoc-style documentation since FlashDevelop and FDT use it for code hinting and it used to help me a lot, but since nowadays I’m coding way more JavaScript and the editors I use don’t support JSDoc I don’t think it pays-off…
Read more…

I’ve just released a new open source project called JS-Signals. It’s an event/message system similar to pub/sub and DOM2 Events but that doesn’t rely on strings to broadcast/subscribe to events, it has also some extra features that usually aren’t available on the other systems.

JS-Signals was heavily inspired by Robert Penner’s AS3-Signals but it is NOT a direct port, which means it has a different implementation and features. I’ve also stolen borrowed a few ideas from Joa Ebert fork ;).

Make sure you read the comparison between the different event systems and the usage examples.

Download it and get more info at http://millermedeiros.github.com/js-signals/.

Ideas and contributors are welcome!