It has been almost two years since I decided to go public with RightJS and on this occasion I'd like to post some reflections on it.
Those days, thanks to github, it's pretty simple to start an open-source project. You just make a repo, write some awesome stuff and push it under the "I don't owe you shit" license. And I like it, in most cases that's all you really need. But, as fun as it is, there is actually another level to open-source projects. The level, where you decide to get serious about it and go public with your project. With promotions, users, official site, docs, tutorials and so on.
It is not completely necessary to make your project kinda "officially public", in many cases it might be even a bad idea, because that will distract you from the actual programming, but there are several important things in this process, which can be pretty valuable as well. And that's what I'd like to write about today.
It Will Make You A Better Programmer
The trouble with programmers is that we work in this area where most people don't really understand anything. And because of that, at some level, programmers tend to start thinking that they are pretty darn smart and kick ass.
A healthy portion of self-esteem is not a bad thing, it might help you to overcome some small obstacles on your way, but for a programmer as a knowledge worker it is crucial to stay hungry for new information.
And running your project for real, will give you exactly that. If you do something interesting enough, people will respond, they will throw all sorts of ideas at you, they will criticize and they will like (hopefully :)) some parts of your work, which will give you all sorts of new information.
With new information you'll face new problems and discover new ways to solve them, and that will make you better at what you do.
It Will Make You More Organized
It is not a secret that many developers don't like TDD and Tickets. Even the ones that do, often cheat and don't cover everything, don't document bugs and so on.
But, when you start an open project for real, you will have to deal with those things. You will have to handle tickets, document bugs and cover everything you can with tests so that folks who use your code had a hight quality experience.
More of that, most open-source projects, especially individual ones, are just about "scratching your own itch". It is highly doubtful that you will make any real money directly from your project, and as much as you might enjoy the creative process of writing code, at some point, you will have to get pragmatic about what you do.
You will need to start thinking strategically, where is it worth to invest your time and where it's not. And that is a highly valuable skill, not just for developing a software project, but genuinely in life.
It Will Make You Better With People
Well, you know what they say "all programmers are bad with people" :). The thing is, that people are irrational, even the smart ones. And there is only one way to learn how to deal with irrational - by accumulating experience.
One of the hazards of the trade is that programmers spend most of their time with computers, and that's certainly not a good thing for your social skills.
When you run an open-source project you will have to handle contributors and do that nicely. Because contributors are privilege. But as all people have different coding styles, different ways to approach issues and just different personalities, you will learn how to find common grounds with different folks, how to work together and how to coordinate the changes.
Conclusion
I don't want to sound like an open-source project is the most awesome thing that might happen to you. By the end of the day, if you're vicious bastard then all that will help you is an old-fashioned kick in the ass.
But, if you're interested in software-development, if you want to learn why and how the things done, running your own project for real might be very insightful and teach you quite a few things.
Thursday, April 28, 2011
Monday, April 4, 2011
Making Tags With Rails And RightJS
As the tags widget appeared recently on the RightJS UI list, I'd like to write a simple how-to about tags in case of using RubyOnRails.
You can see the tags widget in action on this demo page, and over here you can find a demo rails application that has the tags feature implemented, along with some other right-rails features.
Let's start
The Initial Model
When you need to add a tags feature in a ruby-on-rails project, a standard model would look kinda like that
As you can see, it's a pretty much straightforward m2m association, articles have many tags and tags have many articles.
Tags To Strings Conversion
The next standard step is usually to add a couple of methods to convert the list of tags into a coma separated string back and forth. The basic reason is that tags are data-base records and it's not much of user-friendly to use integer ids
After that you can use this proxy property in forms directly, like that
This way the user will always manipulate the tags list as a simple string and your app will automatically create the tag records and associations on fly
Hooking Up RightJS
At this point your rails app will present a kind of a standard and simple case of tags handling. Time to make it look nice and friendly with a bit of javascript.
To hook up RightJS into your Rails application all you need is just add the right-rails gem into your Gemfile
And run the following code generator
Don't worry when you see a tall list of scripts it copies into your public/javascripts directory, right-rails handles most of them automatically, so you won't really need to look inside of those.
Adding The Tags Widget
Ironically, the actual RightJS part of this enterprise is the shortest one. Once you added right-rails into your application, all you need to do is replace 'f.text_field' with 'f.tags_field' in your form
RightRails handles everything else automatically, it generates all necessary html, includes javascript/css modules, it even switches between minified and source builds of javascript libraries depending on the working environment.
More of that, it can automatically use the google hosted rightjs cdn-server for a superfast, shared scripts delivery.
Adding Autocompletion
By default the f.tags_field will make you a pretty looking tags-field, if you want to add the tags autocompletion feature to it, all you need is to specify a list of known tags in it
There is also a few additional options you can use with tags widgets, you can find them at the rightjs.org documentation
Conclusion
This is a good example to show how RightJS is build with server-side developers in mind. As you have noticed we didn't write a single line of javascript in our little exercise, not like we couldn't, just we don't have to bother with those routine things every time we need a simple form with a bunch of standard widgets.
More of that, if you take a look into your HTML code, you'll see that RightRails didn't write a single line of script either, all it did is added the data-tags attribute to your input field.
This way, even if something will go wrong, the user will still see the standard input field with coma separated tags. All your styles and content will remain were it was.
--
Well, this is pretty much the whole story. If you're interested, go check the RightJS UI collection, it has many more useful widgets that you can use in your applications.
You can see the tags widget in action on this demo page, and over here you can find a demo rails application that has the tags feature implemented, along with some other right-rails features.
Let's start
The Initial Model
When you need to add a tags feature in a ruby-on-rails project, a standard model would look kinda like that
class Article < ActiveRecord::Base
has_and_belongs_to_many :tags, :uniq => true
end
class Tag < ActiveRecord::Base
has_and_belongs_to_many :articles, :uniq => true
validates_presence_of :name
validates_uniqueness_of :name
end
As you can see, it's a pretty much straightforward m2m association, articles have many tags and tags have many articles.
Tags To Strings Conversion
The next standard step is usually to add a couple of methods to convert the list of tags into a coma separated string back and forth. The basic reason is that tags are data-base records and it's not much of user-friendly to use integer ids
class Article < ActiveRecord::Base
has_and_belong_to_many :tags, :uniq => true
def tags_string
tags.map(&:name).join(', ')
end
def tags_string=(string)
self.tags = string.split(',').map do |tag|
unless tag.blank?
Tag.find_or_create_by_name(tag.strip)
end
end.compact
end
end
After that you can use this proxy property in forms directly, like that
<%= form_for @article do |f| %>
<p>
<%= f.label :tags_string %>
<%= f.text_field :tags_string %>
</p>
<% end %>
This way the user will always manipulate the tags list as a simple string and your app will automatically create the tag records and associations on fly
Hooking Up RightJS
At this point your rails app will present a kind of a standard and simple case of tags handling. Time to make it look nice and friendly with a bit of javascript.
To hook up RightJS into your Rails application all you need is just add the right-rails gem into your Gemfile
gem 'right-rails'
And run the following code generator
rails g right_rails
Don't worry when you see a tall list of scripts it copies into your public/javascripts directory, right-rails handles most of them automatically, so you won't really need to look inside of those.
Adding The Tags Widget
Ironically, the actual RightJS part of this enterprise is the shortest one. Once you added right-rails into your application, all you need to do is replace 'f.text_field' with 'f.tags_field' in your form
<%= form_for @article do |f| %>
<p>
<%= f.label :tags_string %>
<%= f.tags_field :tags_string %>
</p>
<% end %>
RightRails handles everything else automatically, it generates all necessary html, includes javascript/css modules, it even switches between minified and source builds of javascript libraries depending on the working environment.
More of that, it can automatically use the google hosted rightjs cdn-server for a superfast, shared scripts delivery.
Adding Autocompletion
By default the f.tags_field will make you a pretty looking tags-field, if you want to add the tags autocompletion feature to it, all you need is to specify a list of known tags in it
....
<%= f.tags_field :tags_string, :tags => Tag.all.map(&:name) %>
....
There is also a few additional options you can use with tags widgets, you can find them at the rightjs.org documentation
Conclusion
This is a good example to show how RightJS is build with server-side developers in mind. As you have noticed we didn't write a single line of javascript in our little exercise, not like we couldn't, just we don't have to bother with those routine things every time we need a simple form with a bunch of standard widgets.
More of that, if you take a look into your HTML code, you'll see that RightRails didn't write a single line of script either, all it did is added the data-tags attribute to your input field.
<input data-tags="{tags: ['one','two','three'}" value="one, two"
id="article_tags_string" name="article[tags_string]" />This way, even if something will go wrong, the user will still see the standard input field with coma separated tags. All your styles and content will remain were it was.
--
Well, this is pretty much the whole story. If you're interested, go check the RightJS UI collection, it has many more useful widgets that you can use in your applications.
Subscribe to:
Posts (Atom)