hasan's blog (বল্গ)

i had no experience of using emacs as development environment, so never had any knowledge about emacs color scheme. once when i had been to norway for an official task, i met with one of our escenic colleague “harald khur”.

i was surprised while i had a look on his intelliJ idea color scheme, it all was dark, at the beginning i had a belief that dark color is stressful for eyes. recently when i got introduce with TextMate and their dark color scheme, i was really impressed.

so i didn’t make any delay to let harald know about my interest on his color scheme. he sent me his generated scheme for intelliJ idea. it was simply awesome.

here i have added screen snap of one of my ruby code in dark scheme. i have also attached my modified color scheme as well as the original one, which i received from harad.

modified intelliJ idea emacs color scheme

original intelliJ idea emacs color scheme by harald

i was wondering how i could make my test method more organized and DR(Y)ied.
so i had a nice time while i was writing test to ensure my current modification works ok with existing setup.

i don’t know whether any design pattern or best practice is already exist on this topic.
i came up with something that is really good for me. here is a bit about my task and also the explanation about what i did.

i have a model “category” where i have the following relations -

has_many :category_mappings, :dependent => :destroy
has_many :items, :through => :category_mappings

has_many :categories, :foreign_key => “parent_id”, :dependent => :destroy

has_many :attribute_category_mappings, :dependent => :destroy
has_many :properties, :through => :attribute_category_mappings

belongs_to :category

i was applying :dependent = > :destroy with the mapping model and child categories, which are needs to be removed as a part of the category destroy process.

so i had a messy unit test method to ensure this is working fine. sorry for not keeping my old code snaps otherwise i could show the messy one. anyway here what i wrote later to make it bit cleaner than the previous messy version -

def test_destroy_category_with_dependent
category = Category.find(3)

# prepare for verification
prepare_for_verifying_related_property_mappings(category)
prepare_for_verifying_category_mappings(category)
prepare_for_verifying_child_category(category)

# perform action
category.destroy

# ensure the action
assert_raise(ActiveRecord::RecordNotFound) {
Category.find(category.id)
}

# perform verification
verify_related_property_mappings(category)
verify_related_category_mappings(category)
verify_related_child_category(category)
end

here i just sliced my test method in 2 different roles,

1. preparation stage
2. verification stage

1. preparation stage -
in this stage, i just keep log for current state or other steps which are important for later testing.

2. verification stage -
in this stage, i just verified my new state comparing with the old state (which was kept during preparation stage).
so let’s have a look on the typical code which i wrote in  my preparation and verification stage -

def verify_related_child_category(p_category)
puts “verify related child categories – #{p_category}”
now_category_count = Category.count
assert_equal(true, ((@old_category_count – now_category_count) > 1),
“No category has been removed.”)
end

this seem pretty good for me, as long as i can make my code bunch simple and easy to change.

best wishes,

i was refactoring our Item model, where we have 3 has_many with 3 mapping models.
as we are not using InnoDB based foreign key constraint, we were searching some sort of reliable solution,
which will take pressure in application layer instead of leaving it to the database.

so later we introduced “:dependent” with has_may relation. here is our top of Item model.
has_many :category_mappings, :dependent => :destroy
has_many :categories, :through => :category_mappings

has_many :property_values, :dependent => :destroy
has_many :properties, :through => :property_value

has_many :item_location_mappings, :dependent => :destroy
has_many :locations, :through => :item_location_mappings
our “dependent” flagship is destroying all related items in the item destroy process which has introduced
our flexibility and reduced a lot of code to manage such stuff in a DRY(ied) manner.

so the following unit test worked fine for us.

some bad side,
dependent delete each and every item one by one, which is big issue when you have a big chunk of dependent data.
but that is not suppose to be common in every context. we have no problem with this issue.

best of luck!

“work for fun”

yesterday, i had a pretty rough working day, i was stucked (along with my team) with some simple joining. we had the following models -

Attribute
———–
class Attribute < AR:B
belongs_to :category
end

class AttributeValue < AR:B
belongs_to :item
belongs_to :attribute
end

class Item :attribute_values
end

rails wasn’t giving much better error message, instead it was saying, “invalid type, String to Integer..”, so far i understood ActiveRecord stuff was trying to cast a string to integer.

we even didn’t know which field was doing this stupidity and so on…
so later we dug down to the rails scripts, we added few debug messages. we found “[]” was invoked to set “id” string value.

anyway, after digging more into to this issue, today i gave another try after 7 hours of nice sleep. it was about rails reserve words.

though i heard something from the rails community, but i was expecting some message or  errors which explain this issue.

anyway, i always like fail first approach. if something is not possible it should fail first. at least it should return a meaningful exception.

i believe Active Record should be patched with more clear warning or exception, if any reserved word is used for model or controller or others it should let us inform .

i just gathered a few of my known conventions and best practices. i belief this will help many of us.

few of my previously written posts -
usages of “final” keyword in java -

http://www.somewhereinblog.net/blog/hasan/28708715

usages of comment and coding
http://www.somewhereinblog.net/blog/hasan/28704020

let’s check out my recipes -

1. code from your peer developer perspective view.
while you writing your code, always think your code will be reviewed by some other developers, who is not like you,
who is very serious in simple fault and ignorance in writing code. your code will reflect who you are, so better be careful while you exposing yourselves (through writing code).

2. variable convention -
never write short variable name, always write variable which reflects it usages.
for example -

$user = new User() instead of $u = new User(). follow same convention when you have nested “loop”

3. source file naming convention (except java)
set your file name in such a way that will reflect the usages of the file.
for example -

verify_user_authentication.php (or in a packaging manner – user_util_verify_authentication.php). in java you better know how to write package.

4. keep your url domain centric
all urls should be inherited by some specific problem domain for example -

http://abc.com/user/login

http://abc.com/user/register

http://abc.com/user/update

here “user” is problem domain and “login|register|update” are actions or you could say problem.

5. method naming convention -
write method name in such a format that will reflect it usages. or simply make it self describing.
for example -

function verify_user_credentials() {}
def verify_whether_user_profile_is_complete() {}
private void checkUserFlyLimit() {}

6. don’t write query from controller:
build or execute query from DAO or helper or utility or domain itself. don’t put it over controller which limits the reuability and later extendability and interception

7. single concern
while coding, keep your method slim and less concerned about other implementation. for example -

private void isAuthorizedUser(pUser, pAction) {
if (userAlreadyLoggedOn(pUser) && userIsNotBlocked(pUser) && userHasPermission(pUser, pAction)) {
// boooooooooooooooomm…
}
}

8. think from testability
while writing your code always think from testable perspective view. this means, how you could testify your work or module
or bunch of code which your company is paying for.

9. follow coding norms -
i. think before coding

whatever you want to put on your code try to think or imagine before start coding.

ii. dump your think in comment

whatever you thought just write it down over comment or paper or in a common place where you or future developers could have look on. (better place in comment)

iii. write your algorithm in comment.

whatever you planned write in comment before kick start your coding.

iv. set up your unit test case.

find all probable assertion points from use case, put them over your unit test case.

v. write your code
vi. coding routine -

(1) test -> (2) code – go to > (1) [recursively]

10. always put your tag over the source file,
whatever you wrote, that reflects your confident and work efficiency, so better you tag your name over every source code you have written or modified. good for tech lead or project manager, because tagging each file with author name, it creates a hidden responsibility for the author good for both parties.
for example -

/**
* @author someone
*/

those who doesn’t know about JETTY RUNNER:
JETTY RUNNER is a standalone swing based application which is used to bundle java ee based application along with jetty container. it comes with simple web app configuration xml file and global properties manager through a simple properties file.

actually i have been using this project for my own development solution, so i belief this project will become a great strengthen feature gradually.

JETTY RUNNER is now running on max OSX, i have removed system try support in new tag v-0.2, soon i will release *.dmg package for mac osx. here are few screen snaps -

figure – 1: server console main window

figure – 2: global properties editor

change logs -
1. removed system tray support
2. removed default jmx configuration
3. added “start.sh” to launch JETTY RUNNER on *nix based platform where ruby script is installed.
here are few screen snaps, which i have taken from the newly added ruby script! -

figure – 3: newly added jetty runner on ruby

figure – 4: newly added jetty runner implementation in ruby

this script really great , at least i like it

i have been practicing test first development (from TDD) approach for last 1.5 years. i wrote a lot of junit test cases and wrote a lot of jmock based mock objects. it was amazing work with it these tools. specially jmock was fantastics and my most favorite mocking tool.

anyway, while i seriously started ruby on rails it is about 2/3 months ago, when i formed my own rails team and started working on first commercial rails project.

at the beginning i was working on IntelliJ IDEA 6M2 on windows environment, where i found running runit test cases are taking longer than we suppose to expect. it was really annoying.

good luck i got my mac book pro where i set up all rails stuff with IntelliJ IDEA 6M2. now i could see a lot more significant difference. now i am really feeling my test environment for rails project over this environment is running more than i expected. it really leads me to belief test driven approach over rails environment is really fast.

it must be some platform related significant changes, which only the expert on that platform can assure me.

by the way, i am really loving intelliJ IDEA and rails over my mac environment.

indeed nothing is special, but this post is about to remind me about the steps i followed to get my mac box with maven and jdk 1.5.

my requirements -

1. maven – 2.0.7
2. jdk 1.5
3. set maven bin to PATH variable.

i had 10.4.10 osx version.

to configure jdk 1.5 (jdk 1.4 is set as default jdk):

cd /System/Library/Frameworks/JavaVM.framework/Versions
sudo rm CurrentJDK
sudo ln -s 1.5 CurrentJDK

to configure maven:

download maven binaries, copy it in your preferred location.
in my case i had it in – /Applications/java/maven-2.0.7/bin/ here.

execute following line -

vi ~/.bash_profile

change PATH with following value -

PATH=/usr/local/bin:/Applications/java/maven-2.0.7/bin/:$PATH

test your configuration -

java -version
it should say – java version “1.5.0_0x”
mvn -version
it should say – Maven version: 2.0.7

thats all will make your maven and jdk 1.5 environment up and running.

these days i am having a lot of fun with Ruby on Rails. it seems to be like an open ground with lot of handful tools, now come up with ideas and build them up.

handful ruby based tools really helping me to let my smile back. anyway, while i was writing code on rails i am feeling something can be better practice something is not good. from now on, i will try to put them over the my blog.

their is method called “layout” which is used to define the based layout for the controller. this can be used from ApplicationController and other domain specific controller for example : “UserController”.

my team and me was used to define layout over the domain specific controller, but i belief, as we are repeating same “layout ‘template1′” code over and over, it must be better to keep inside the ApplicationController, as because all domain specific controllers are extending application controller, more over it is easy to change.

you may get a question about ajax based response, the better answer is, use render .., layout => false, that will get rid of base layout.

best wishes,