Although logging is very important part of a software, there’s no too much information about it like about writing good software documentation. Developers know that it’s a mandatory step, but usually here the story ends.

Log is the story of the software, like a story of a book. Later the story becomes to history and finally it ends as a garbage. People write books, because others are interested about the story. If the story is untraceable, people stop reading. Logging is writing a story. If the story untraceable, the log is unusable. How can you write good log entries in a software? I hope this short page can answer this question.

Usually I use Thesaurus to find synonyms for a variable or method name when I don’t want to use conventional names. These names can be parser, processor, handler, entity, object, manager, go on. So trying to find some phantasy name for them just makes code colorful (like Railtie in Rails).

I love Sublime, because I don’t need to jump among the windows while I’m working on a project, I can do many things just in the editor using plugins. Run the tests, open GitX to prepare my commit, see git annotate, push my branch, run a command in console. Unfortunately there was no way to look for synonyms of a word and I didn’t find any plugin either. I spent a little time to create one, so here is a very simple plugin to use Thesaurus in Sublime. Just select the word (or press (CMD/CTRL)-G where the cursor is) and press (CMD/CTRL)-T. Synonyms pop up in a list window and the word in your code will be replaced as soon as you choose the right one from the list.

To install just follow the steps in the project’s documentation:

https://github.com/Nucc/Thesaurus

I’ve been trying different keyboard layouts for a long time, because I feel tension in my wrist after a long day spending it with programming. Change to something new is not easy when you have to keep your old habit in work to be productive. I’ve been using querty since my childhood and I have a lot of bad reflexes for words when I use wrong fingers (usually I use my middle finger when I should use my ring finger, and use my little finger only for shift, enter and backspace). As a programmer I have to use punctuation chars like []=-_ more times than other people do what breaks my typing, especially for = what is very used in a program code and I can reach it only with my little finger. Moreover I experienced many mistypes so I use backspace more as it would be normal. This is a 3-day-long weekend here in Ireland, so I decided to polish my layouts and practice a little bit.

By default Mongomapper and Mongoid supports dynamic fields when you can store any value in MongoDB independently of the documentation schema. It can be really annoying when you’re working with many others and the software is getting bigger, since unknown fields can appear in the database which are used from one method but didn’t defined in model schema. Or just guess what happens when somebody makes a typo error and stores the first_name of the user to the fist_name attribute. Your mongo-mapper library won’t warn you about the error, just create the new wrong attribute and store it in the database.

I don’t like this kind of hidden information in the software because it just increases the complexity, so I was googling to find an option or something to turn this feature off. Mongoid has option to do this, but unfortunately in mongo-mapper it’s unsupported. So I forked down from mainline and created a patch on Github.

Today I was playing with Padrino session handling. Padrino provides a session variable to store user specific information. I don’t like to use this session variable directly all the time, I believe in data encapsulation to hide its logic and give only an interface to reach session info. Since the recommended size of session object is lower than 4Kb, I usually store only primary keys in the session store and build up the object according to this key. So if I use an own-defined SessionStore to hide the session handling logic, the SessionStore.user would return my User object, and it’s nicer than using  User.find(session[:user_id]) every time when I want to use the actual user. By the way I can implement caching logic to SessionStore to reduce the database hits.

In Padrino when you want to create a test file, you should use the test_config.rb in /tests directory. If you create a model by generator, your code looks like this:

1
2
3
4
5
6
7
8

require File.expand_path(File.dirname(__FILE__) + '/../test_config.rb')
 
describe "User Model" do
  should "construct a new instance" do
    @user = User.new
    refute_nil @user
  end
end

require File.expand_path(File.dirname(__FILE__) + '/../test_config.rb')

describe "User Model" do
  should "construct a new instance" do
    @user = User.new
    refute_nil @user
  end
end

I usually play TDD, so when I need a model I just create the test file and step by step adding the additional files which are required by the test. The first line of the previous snippet is just pain in my ass! I don’t want to write this in my code, I just want to use it like in Rails:

Playing with TDD would be better if I could save the stable points of my software and use the description of the new testcase as git commit message too. I needn’t make any git commit, since when I say “User should have name” in my testcase specification, it contains all the information about the changes in the code. So my idea is to use the ruby spec files to generate git commits.

I created a proof of concept and released it on rubygems.org.