Blog Improve It

MacRuby

Posted by Vinícius Teles over 3 years ago.

Versão em português

Do you like Macs' graphical user interface? Who doesn't? It's one of the highlights of the Mac and the iPhone. It's based on a technology called Cocoa.

In the Mac it's possible to create graphical user interfaces using Cocoa easily with Interface Builder. So one can drag components around, setup actions and establish connections with the code which is implemented in Objective-C.

Objective-C is an object-oriented programming language which adds Smalltalk-style messaging to the C programming language. It's a very interesting programming language, although a very verbose one. For those who want to create desktop applications on a Mac, or iPhone apps, it can represent a significant barrier. The language is arguably harder to use when compared to others like Ruby.

Ruby is a programming language created with the purpose of making programmers' life easier. It's simple, elegant, easy to use and very expressive. It's also adored by those who use it including myself. :-)

So, on the one hand there is this incredible technology for building graphical user interfaces, called Cocoa, and on the other hand, there is this amazing language called Ruby. Wouldn't it be great if we could use them together? Well, it turns out that this has been possible for a while using, for instance, RubyCocoa which bridges Ruby and Objective-C. But nowadays there's a better option called MacRuby.

From MacRuby's website: "MacRuby is a version of Ruby 1.9, ported to run directly on top of Mac OS X core technologies such as the Objective-C common runtime and garbage collector, and the CoreFoundation framework. While still a work in progress, it is the goal of MacRuby to enable the creation of full-fledged Mac OS X applications which do not sacrifice performance in order to enjoy the benefits of using Ruby."

In the last few days I implemented a feature using MacRuby and Cocoa. It's something useful to us, although pretty basic. It helps us to setup new domains in the DNS of our Slicehost account, where we host our applications. I'll make the code available at GitHub soon.

I found it easy to implement this feature using Cocoa and MacRuby. It showed me that the purpose of the MacRuby project has been achieved at least in this specific case. That is, it really made it much simpler to implement this feature, compared to the Objective-C version of it.

So I'm very enthusiastic about all that can be done with MacRuby. I'm particularly thrilled with the ease of use and increased speed of development. So I'd recommend everybody to take a closer look and learn it.

I should probably mention that I had some previous knowledge of Cocoa and Objective-C before implementing this feature. I've been using the book Cocoa Programming for Mac OS X as a reference so far.

I'd like to thank Matt Aimonetti who kindly introduced me to MacRuby when he was in Rio recently.

If you're not excited about this project yet I offer you a few more informations. MacRuby is sponsored by Apple itself who seems to have a great deal of interest on it. As a matter of fact, the project creator, Laurent Sansonetti works for Apple and spends most of his time on MacRuby. Why?

Among other reasons, it's probably because in the near future, we might be able to develop iPhone apps using MacRuby! And that opens the gate for many Ruby programmers who will be able to create iPhone apps using their favorite programming language. So, if you're not yet programming in Ruby, maybe this is the excuse you've been looking for. ;-)

Tags  | 2 comments

How to write specs in Sinatra using RSpec

Posted by Vinícius Teles over 4 years ago.

I worked on a small app recently where I chose to use Sinatra. When I tried to write the specs, things were not as smooth as I would expect. Fortunately, I found this great article on how to use RSpec with Sinatra. I hope it can be helpful to you too.

Tags  | no comments

New Selenium-on-rails is out

Posted by Marcos Tapajós over 4 years ago.

selenium

I'm a little bit late with this post but I think that its publishing may be useful.

I started to use selenium-on-rails plugin almost at the same time that I started to work with Rails and after that I couldn't develop any system without this kind of test. Because of my dependency on this plugin I created a lot of fixes and improvement.

I don't know why but for a long time this plugin was abandoned and a few months ago it received a new mainteiner called Eric Smith that invited me to become a committer and we started to work together. I need to cite that before that, Ryan Bates had done a great job making the plugin compatible with Rails 2.0.

When Eric became the mainteiner he created a project at github and it has become easier to contribute. Some people started to contribute after that, like Nando Vieira.

It is impossible not to admit that the open source world changed after the github.

Two weeks ago we launched the new version of the plugin and now it is compatible with Rails 2.3.2 and, until this post, compatible with Edge Rails too.

I would like to say "thanks" to everybody who cooperated eventhough I probably forgot some names.

Well, Enjoy it!

Tags  | 8 comments

Highrise API

Posted by Marcos Tapajós over 4 years ago.

A few weeks after the launch of Be on the Net we are very busy with a lot of operational tasks and discovered that we need to automate some things.

Vinícius started the automation a few days ago using a lot of resources available in Mac Os but it isn't enough and today he asked me to start the development of our CRM.

Until now we are using the Highrise and we are very glad but we need some things that are not available. Maybe these things are very specific to our company, maybe not. By the way, we have decided that we don't want to recreate the wheel.

For me Highrise is the best software from 37Signals and there are some things that are very useful to us and that is why I started to develop our CRM using the Highrise API to integrate the two systems.

I didn't find any good gem or plugin to communicate with the Highrise but I found the "Ruby wrapper for the API" from 37Signals. This code works but it is very badly organised, with all classes in the same file and without any line of test.

I think that this is only an example and to make it usable I created a plugin based in this wrapper. I reorganized, added tests and rewrote some parts of this code to use in our CRM. After that I decided to make it public and converted the plugin into a gem and published in GitHub at this url.

http://github.com/tapajos/highrise

I would like to have more time to improve the documentation and add a lot of examples but it isn't possible now. I think this isn't a problem because this code uses the ActiveResource and it is very documented.

After a day working with Highrise APi I discovered some good and bad things.

1 - All the queries are VERY SLOW. Really VERY SLOW! More than 35 seconds to retrieve a list with only 200 records. 2 - The API didn't provide any way to retrieve the tags of one person. 3 - I still think that Highrise is very good and our CRM integration the two systems are possible.

I will send this post to 37Signals and I hope that they try to solve the problem with queries speed and add tag support in the API.

Tags  | no comments

Databases don't scale. YET!

Posted by Marcos Tapajós over 4 years ago.

cdb2

Everyone who is following me and Vinícius knows that we were making some experiments using CouchDB. Some people were asking why couchDB? The answer is because this is a different kind of database and sometimes we have problems with the traditional ones and we never found a definitive solution.

Before working for Improve It I had worked in a project using Java, with so many web-servers, applications servers, load balance, queue and everything that it was necessary to scale an application but the performance was terrible. The system users hated them and us! Basically the problem was because the database was very big and shared with other systems.

Vinícius worked with some clients with similar problems and they spent a lot of money with DBAs and contracting companies specialized in creating clusters of databases without success or with partial success.

Experience tells me that every big system has problems scaling database. Recently, at the Rails Summit, I watched the Phusion guys speech about the difficulty to scale databases and that this was the real problem. I agree with everything that they said.

I think is very easy to scale Ruby, Java or any other language adding more machines, memcached, queue and a load balance. But it is irrelevant if your database doesn't support all the accesses.

Some people say that Ruby is slow, Rails doesn't scale and that Java is the solution to every problem of the world but they forget to say how they solve the database problem. I was very curious to know how.

Of course it is possible to do some things to "solve" these problems. If this were a problem without solution probably systems like Flickr would not exist. The question is not having a solution but having an easy solution. In my opinion the answer is not with traditional databases.

Relational database isn't a bad thing. It was developed before the internet and it was meant to solve very different problems than the actual problems and now it is time to create other solutions. CouchDB is one of these solutions bus isn't the only one. You can try others like SimpleDB.

Some people will criticise us and say that they knows solutions using Oracle, MSSQL or whatever. I would like to ask these people to think if these solutions are simple.

Because of these bad experiences we hate traditional databases and decided to try another paradigm for databases. We decided to study this database migrating one from our system to use CouchDB and only after that stating an opinion. We love trying new solutions and hate talking without knowledge. :-)

After almost a week working hard on the system, we finished the migration and we were very happy with the results! Now I will share some things that I learned this week.

CouchDB was developed using Erlang and now I know that it is more than a distribution! Erlang is a general-purpose concurrent programming language and runtime system created by Ericsson to support distributed, fault-tolerant, soft-real-time, non-stop applications. It sounds good to me! It is everything that I wanted.

Instead of storing data in rows and columns, the CouchDB manages a collection of documents; JSON documents. I'm not sure but I think it is now supporting XML too. Well, it isn't columns oriented and without a schema. All documents in CouchDB are versioned.

The CouchDB uses views(design documents) defined with functions to aggregate datas and filters to be computed in parallel. This database is very much based in MapReduce principles. The index of the views are updated continuously.

Instead of a SQL CouchDB uses Javascript by default but you can add support for other languages.

CouchDB is accessible via a RESTful JSON API. It is very good because you can put a load balance in front of a lot of databases. For me it is great and represents part of the solution to scale databases!

cdb1

The last thing I discovered in CouchDB was how easy it was to make replications. You just need to say what the origin and destination urls are and then wait. It is really very easy and FUN. Vinícius was crazy about it when I decided to try to make some replications! I stole his notebook and put my notebook in an infinite loop to generate very big documents and started the process so many times to analyse the performance and how to work with the bi-directional replications.

I'm not an specialist in databases. I wrote about my impressions and why I chose this database to study. If you aren't happy with your database try to study it!

Tags  | 11 comments

Margins on the HR tag: a case solved

Posted by Leandro Mello over 5 years ago.

Basically, the smack on the head that makes IE behave is display: block. After that, you can play with whichever margins you want on <hr />.

I am one of those who use the <hr /> tag to split sections. It’s semantically more coherent than dividing by styling the very divs’ borders, it looks better when you view the HTML without CSS, and all that stuff that’s been discussed a lot all around. I came to appreciate <hr />’s usefulness.

The fact, however, is that it’s a pain to style this tag. For each browser different attributes must be edited in order to achieve the same effect. With some working, the <hr /> gets the same look in every browser.

What really makes people all over forums pull their hair out is the damn margin that surrounds the <hr /> in IE. IE’s margin is stubborn, indestructible, uncontrollable, unstylable. Wherever I looked for, people gave in to adopting the margins, and more persistent designers even encased the <hr /> into a <div> to get the desired style. In other words, some gave up too easily, some took desperate measures and wouldn’t care to make things right.

One day, I stumbled upon two blog articles which came near to a solution. Neither of them solved the case by itself. But joining both, it worked! Tests confirmed that by mixing both theories I could attain any margin size I wanted, in every browser — even zero. But, in a very unfortunate turn, I never bookmarked such articles, nor have I saved my test files. A very looked-for answer, lost in such a silly way...

This article is about my specific case: I wanted to use <hr /> free from any nonsense divs, and with zero margin — even in IE. And, above all things, this article is all about leaving the answer somewhere safe and under everyone’s reach. Now that I’ve remembered the solution, I won’t lose it again.

“Smack that head”

After I’d lost track of those articles and weeks had passed by, all I could remember was that Internet Explorer needed a smack in the head: a completely unexpected, counter-intuitive attribute that would get it back to its senses. Basically, the smack on the head that makes IE behave is display: block. After that, you can play with whichever margins you want on <hr />.

Who figures. The <hr /> element is already a block. In every way it looks like a block element. Breaks line above, breaks line below, there’s nothing inline on it. And that seems to be why so many forums chase their tails for a solution: few would suspect that it is necessary to remind <hr /> that it’s actually a block. Saying display: block would be plain redundant and unnecessary. But damned IEvil demands it in order to realize “oh well, what do you know, it’s true...”.

How it happened to me:

On with my case. I wanted to add some <hr /> tags to Brazilian photographer Patricia Figueira’s site, as an experiment for future execution on her own site, as well as on our currently under development product, beonthe.net.

First step was to insert those tags in the spaces between header, main content and footer. Let’s see the HTML:

<div id="header">
  (header content)
</div>
<hr />
<div id="main_content">
  (main content)
</div>
<hr />
<div id="footer">
  (footer content)
</div>

And came out the gray line between divs. Like this:

Safari: Hr was added correctly.

Opera: Hr added correctly as well.

Firefox: Hr added correctly, just like the others.

Internet Explorer 7: Hr was added correctly, but had margins that pushed away the divs’ content.

Internet Explorer 6: Hr was added correctly, but also had the margins that pushed away the divs’ content.

(Boy, that’s IE...)

Once inserted, I wanted each divider line to have the following features:

First task is simple. In our style sheet application.css, we write:

hr {
  clear:      both;
}

Now comes the second task: cleaning the spaces the line generates on IE. But as said before and so many times on blogs all around, <hr />’s margin on IE is persistent, ruthless, stainless, shameless. People around have tried everything: margin: 0, padding: 0, line-height: 0, font-size: 0, even overflow: hidden. Going margin zero works with standard-compliant browsers, but nothing beats those gaps on IE.

So, in our application.css, let’s guarantee there’s no margin on the smart browsers:

hr {
  clear:      both;
  margin:     0;
}

The explanation for IE’s insistent margins is that IE renders the <hr /> tag with a vertical margin 7px longer than other browsers. In other words, if you write...

hr {
  clear:      both;
  margin:     7px 0;
}

... You get, in a decent browser, the expected: Exactly 7px up and 7px down.

And on IE, a sum of what you wrote plus its native margins: 14px up and 14px down (7 + 7).

“So”, I might think, “I just have to write negative margins for IE”. Would be the intuitive thing to do, but IE isn’t all about intuitiveness. It won’t work: the upper margins goes away, but the lower one never gives in! Check it out: The hr tag gets upper space = zero, but the lower space doubles: it takes the upper space’s 7px for itself!

The ace in the hole

Enter in our application.css the attribute display: block:

hr {
  clear:      both;
  margin:     0;
  display:    block;
}

This is the last attribute I’d think about to eliminate margins. I can’t explain why it works. It’s counter-intuitive. It’s redundant. It’s idiot. And nevertheless (or perhaps just because of this) it makes IE wake up.

Now we can think about that negative margin subject. Then we just correct application.css:

hr {
  clear:      both;
  margin:     -7px 0;
  display:    block;
}

And voilà! Finally, an <hr /> tag with no margins! Not an illusion! It IS possible to totally eliminate an hr’s margins on IE!

Conditional comment:

Problem with using negative margins is that standard-compliant browsers interpret them just as they are — negative: Negative margins on Safari.

We have to set a behavior for each type of browser.

I’m used to using conditional comments. Some say they are bad, but so far they have but helped me a lot.

On to the <head> on HTML. There we insert a condition for IE:

<!--[if IE]>
  <link href="/stylesheets/application_ie.css" media="all" rel="stylesheet" type="text/css" />
<![endif]-->

It’s purpose is to call a style sheet with rules exclusively for Internet Explorer: application_ie.css.

In this new application_ie.css style sheet, we apply the negative margins we had up to now:

hr {
  margin:     -7px 0;
}

There you are. This is the only rule that distinguishes the <hr /> tag on smart browsers and on Internet Explorer. Now we can go back to application.css and make our margins go zero:

hr {
  clear:      both;
  margin:     0;
  display:    block;
}

And the result is: consensus! On the smart browsers: (Appearance of hr on Safari. It&rsquos the same as on IE!)

... and on IE: (Appearance of hr on IE6. Now every browser’s hr has got the same look.)

Finishing touches

Only the third task’s left, which is to make those lines invisible. This is easy with visibility: hidden:

hr {
  clear:      both;
  margin:     0;
  display:    block;
  visibility: hidden;
}

Which renders the <hr /> invisible, but still taking the room it has been taking before, in a way there’s a 2 pixel gap between the header and the main content: The hr is now gone, but there is still a gap where the hr was before. We have to get rid of it.

Note: Using display: none is useless in this case, because it cancels the clear: both attribute. And we want it to break the floats. In this case, better stick with visibility: hidden.

On the decent browsers, this gap is due to border width. 1px borders around a zero height element result in a 2px total height. A border attribute should do it:

hr {
  clear:      both;
  margin:     0;
  display:    block;
  visibility: hidden;
  border:     none;
}

The gap is now gone on Safari and Opera. But Firefox and IE need a little further push. Remind them the element’s height must be null:

hr {
  clear:      both;
  margin:     0;
  display:    block;
  visibility: hidden;
  border:     none;
  height:     0;
}

Firefox now is okay. But on IE, the gap, instead of disappearing, got reduced to 1px (boy, that’s IE...). That’s because on IE’s <hr /> the borders aren’t defined by the border, but instead by the color (have I mentioned IE isn’t all about intuitiveness?). As one’s color can’t just go “zero” to make the gap go, the way left is to tweak the margins we have on application_ie.css, adding 1px above or below:

hr {
  margin:     -8px 0 -7px 0;
}

And there you have the final result: On all browsers, an invisible divider line with no margins. Mission complete.

Conclusion

This was my very specific case involving the <hr /> tag. If you are one of those people who pulled your hair out because of IE’s stubborn margins, know that there’s a solution. You don’t need to adapt you precious layout to fit the margins, nor you have to enclose the tag within a <div> only for it. Best practices, now!

I hope I have helped relieve your pain in the neck. Now the answer is right here, for the whole world. Soon you’ll see it in action at Patricia Figueira’s site and at beonthe.net. But if this article doesn’t solve your particular case, write me. Let’s think together of solutions for taming <hr /> — and maybe, just maybe, Internet Explorer itself.

Tags  | 11 comments

Where do rants come from?

Posted by Vinícius Teles over 5 years ago.

Have you ever realized how aggressive people tend to be on the net? You probably have. Specially if you're used to participate in online forums. And who isn't?

Rants keep popping at different points quite often. Does it reflect a behavior that is also present in the physical world? Do people engage in rants as often in the physical world as they do on the net?

I don't think so. And most of all, I think the way people approach those rants online are far more violent than the they do in the fewer occasions when they participate in physical world rants. Why is that so?

I believe there are at least two components to the answer. The first one is the nature of the communication itself. The second is the nature of the relationships.

The nature of communication

When we write, we activate different pathways in our brain compared to the ones we use when we speak. This difference seems to influence significantly the message we're trying to convey and most of all, the way we go about it. To understand more about it, check out the excellent Pragmatic Thinking and Learning.

Have you ever caught yourself writing something to someone that you wouldn't say to that person? There you go. It seems to me that we're more sincere when we write. It's as if the act of writing itself opened a window in our soul that allows our real thoughts to flow through. At first sight this would be a good thing. But when it comes to online communications this can be pretty harmful.

Messages written on a paper or online aren't effective ways to convey emotions. This means that identifying the emotional state of the author of the message is an exercise of guessing. A text that looks as if it's been written by a very angry person might have been written by someone who's not angry at all and vice-versa.

Overtime I've learned, the hard way, to not trust my judgement when reading online messages. I should always do my best not to try to guess the emotional state of the authors of the messages I receive. I've been involved in so many problems because of misunderstood emails that I began to use electronic messages much more carefully.

There's one more problem associated with the medium of communication. And this is more of an internet problem. It's easy and fast to communicate on the net. Although we can claim this is good in so many ways, it's also dangerous.

When we write an email, all too often we press the send button without reviewing the message and giving ourselves some time to thing and reflect on what we've just written. This is really bad. Specially because we're opening our souls and being maybe too much honest. It's not to say that honesty is a bad thing. It's just that sometimes, some messages need to be crafted more carefully, specially if the content is somehow sensitive. In our hush we forget to apply some filters that might contribute to the proper understanding of our intents. The funny thing is that if we were to say the same thing to the same person we would probably have filtered many parts or just been careful with the way we talk.

The nature of relationships

The second reason why I think rants arise have to do with the fact that people communicating online often don't know each other personally. And that can make a huge difference.

Take the case of DHH, creator of Ruby on Rails. People tend to create all sorts of bad images of him based on his writings on the net. I had the chance to talk to him in Portland and in Chicago a few months ago. What I realized then is that he's actually a very nice guy. He was very kind to me and anyone else who would talk to him. So I'd say that DHH in person is very different from who we think he is considering only his online "version". As a matter of fact this kind of realization has also come to me in many different occasions when I would have the opportunity to meet somebody that I only communicated with on the net.

Conferences are really great in this sense and thats the part that I enjoy the most. You get a chance to meet people and get to know who they really are. Most of the time I find out they're much nicer in person than I would have expected.

After meeting some people in conferences I would never think of them in the same way again. I always become more understanding and forgiving about their messages online. Since the messages can't erase the fact that I know that person and I know he or she is better than their messages would make me think of them.

Conclusion

To wrap it up, don't give too much credit for your interpretation of the emotional state of the author of a message. Be very suspicious of it. Also, try to pay attention to your writing and even better, if you have something controversial to communicate try to say it in person or just make a phone call. And finally go to conferences and try to meet people and get to know who they really are. By the way, Rails Summit Latin America will take place a few weeks from now. It will be a great place to meet people that you probably only know online. You'll probably be surprised once you meet them in person!

Tags  | 1 comment

Natural Laws of Software Development

Posted by Vinícius Teles over 5 years ago.

InfoQ published a great video of Ron Jeffries and Chet Hendrickson filmed during Agile 2008. They explain how agile practices were derived from natural laws of software development. This is an awesome video. Check it out!

Tags  | no comments

The common denominator

Posted by Leandro Mello over 5 years ago.

On the web, even if you can't show an image, you can still speak the thousand words.

Last Friday I discovered a detail in my method of writing CSS that I intend to adopt as "best practice" for me in every project from now on: the only style sheet which, in a project that includes screen/printing/mobile, should have attribute media="all". I call it "typography.css".

Inspiration come from out of the web

I came up with this method by applying, in web design, some of the modus operandi used by advertisers and designers off-web.

In design and advertising, people are used to dealing separately with layout and typography. That's because design applied to text has itself such a strong personality, that it deserves special attention. There are lots of companies which devote themselves to typography only, and spend days, even weeks, to give birth to a single, complete, beautiful font. The looks of the text hold their very own power.

On the web, we suffer from serious constraints regarding typography. It's impossible to use unique typefaces in a website because they may not exist in the user's computer. Using fancy images for text implies some risks to accessibility, and embedding one's own set of fonts in the code has issues of its own. In a nutshell, patience: we'll just use the cards we're given and know how to play with them. Which is fine, since this article isn't really about typography itself, but what we can learn from the habit of putting it apart from the layout.

Consistency and visual identity

The good thing about CSS is that it ensures consistency throughout one's site pages. One little change in a single selector and voilà, thousands os pages updated at once! That's all about what we call visual identity.

A company that respects its own visual identity demands that, at least, its corporate typography be consistent in every communication medium, whether print or electronic, and as much as possible. Layout schemes may be subject to little adjustments every now and then, because of the diversity of surfaces they can be applied to, but the way text looks must respect an even more global, thorough consistency across media — the designer might one day find him or herself having to make a piece of design that relies solely on typography, and people have to be able to realize just which company such piece belongs to. On the web, relying heavily on text is something that happens quite often.

The common denominator

Imagine your site is whole: printable, mobile-friendly, presentation-ready, almighty. Now strip off all the fancy stuff. Images, layout luxuries and everything. What's left? Text. On the web, even if you can't show an image, you can still speak the thousand words. And can as well spread them to other media. So, why not creating a style sheet that deals only with what regards text?

How it happened to me

As the projects I've been working with were growing, it got more and more complicated to browse through the sea of selectors. Since I write CSS in an incredibly regular fashion, with every property always obeying the same pattern and order (ok, call me maniac), I realized text properties came always grouped before layout properties. To decrease file size, I decided to throw all those text properties on a separate file, which I called typography.css.

So, for an example:

.rss_links a, 
.podcast_files h4 a {
    font-size:              80%;
    text-transform:         uppercase;
    text-decoration:        none;
    padding:                .3em 1em;
    background:             #F7F7F7 url(/images/background/gradient_light_to_dark.png) repeat-x bottom left;
    border:                 1px outset #F7F7F7;
}

... was split in a part that went to typography.css:

.rss_links a, 
.podcast_files h4 a {
    font-size:              80%;
    text-transform:         uppercase;
    text-decoration:        none;
}

... and another one that remained in the original application.css:

.rss_links a, 
.podcast_files h4 a {
    padding:                .3em 1em;
    background:             #F7F7F7 url(/images/background/gradient_light_to_dark.png) repeat-x bottom left;
    border:                 1px outset #F7F7F7;
}

And so on, with all of the selectors. The splitting was quite easy. The decision of making the split and the name of the new style sheet was more due to my old habits as a graphic designer — and a slight hope that it actually decreased file size — than to having any idea of what it would result in (I barely knew, but there would be pretty interesting results).

There is a moment when it's time to make a print and a mobile CSS. On my first experiments since I began using the "typography" method, I decided applying the same principle to the print and handheld media, thus creating style sheets called application_print and typography_print, and application_handheld and typography_handheld.

My "stylesheets" folder then became like this:

Beautiful! But, boy... six style sheets just because I was all into this putting-typography-apart-from-layout designer fuss? "There has to be a better way to do this", I thought. And there was. With the subtle perception that typography (as said a little before) must be global.

Refactoring, results and advantages

I came to realize that the selectors on all of the typography files were very alike. So I mixed up typography, typography_handheld and typography_print into a single typography.css. End of duplication: it would now take care by himself of everything text-related — font size, typeface colors, italics, bolds, capitals and so on. On the print CSS, since people usually prefer printing text in black, I just wrote html * { color: #000; } to make sure everything got black (and made the same to some stubborn selectors that were left).

After all that, in the HTML head, I gave typography.css the exclusive attribute media="all". Other style sheets should concern their own specific media. Thus, all these sheets would inherit the same text properties, which would in turn ensure consistency not only among every page in a website, but across the many media available by a given company and its website. All about visual identity, fellow reader!

This method brought up some other advantages:

The new practice has been bringing me good results. Sure, there are exceptions: in a small project one doesn't intend to print or see in a handheld device, it's just not worth separating typography and layout. On the other hand, a huge project, even one that may have a typography.css, has more chances of having additional style sheets which would probably discredit my "n+1" count. But all in all, working my CSS out is a lot easier when I take care of one thing at a time. That's something I'm going to adopt as best practice on my future projects, that's for sure... until better practices come up! :)

This was my first entry on Improve It's blog. I hope the information shown here has been useful somehow, and inspire designers and programmers some good practices. Up to what I've experienced, this method was one to really make work easier here. Sure, either I haven't read enough about CSS, or this topic about separating typography is already old history around the world, or both of them. That's why I invite you designer fellows to join the discussion (and to aid me with my rusty english!). Who knows how much improved this methodology (and my english skills) can get? :)

Tags  | 1 comment

Integration Plugin with GIT support

Posted by Marcos Tapajós over 5 years ago.

Integration Plugin with GIT support.

intplugin

Since the release of Integration Plugin I was feeling that the plugin needed to have the GIT support but the plugin had been extracted from an existing code and the Improve It team hadn't used this SCM yet.

After the release my friend Eduardo Fiorezi sent me a patch with this support first and afterwards another patch with the git-svn support but I didn't accept because there was some documentation missing and I didn't have time to do it. Today, another friend Sylvestre Mergulhão sent me a different patch with the missing documentation.

Thanks to Eduardo Fiorezi and Sylvestre Mergulhão

Tags  | no comments

Older posts: 1 2