• Loading an temporary image (which already exists in our server)
• Perform Image cropping (using a crop area)
• Perform Image Resize (with and without constraints)
• Perform Rotation (90 degrees CW and CCW )
• Save image
• View Saved image
• View Original Image

• Ajax for postback activity
• JSON(JavaScript object notation) for updating JavaScript image
  
• Rmagick for the image manipulation.

• Currently the wordpress does not give the option to download the Zip file. To receive the source code, please send an E-Mail to info@heurionconsulting.com
• Unzip the source file to a suitable location
• Run “ruby script/server” (for windows) or ./script/server (for others)

• ImageEditor.js – Contains all the code that is necessary to do the image manipulations activity and also to send the post back to the server. This code uses Ajax.Request method to send data to the server. Also the Response is a JSON object which is used to update the client JavaScript image object.
• PageInfo.js – Helper code for tracking mouse position, used to provide JavaScript Crop border.
• Imagecontroller_controller.rb – Contains all server code where image manipulation is performed using RMagick and the resulting images are stored and picked from the respective (edit / active / original) folders.

• ImageFound : Boolean test that the view was called
• ImageName: Holds the new image name
• X: top left- x position of the new image
• Y: top left – y position of the new image
• W: width of the new image
• H: height of the new image

• In this application the image shown in the browser is already in the server. We are taking a single image and modifying around it. We can extend this application by loading user images by using any standard upload methodology. One of the notable Ajax upload feature is what is available in the photo gallery application available in the book “Ajax on Rails” by O’reilly Publications. The code for uploading files from client side is:

• In this application we are currently providing editing the image by crop, resize and rotate using Rmagick. Image rotation is done for 90 degrees clockwise and anticlockwise directions only. We can extend this application by rotating the image in any degrees by Rmagick.

• In this application we are currently resizing the image by giving values in the text. We can extend this application by using grips on the edges of image instead of using text. We can resize the image by dragging the grips in and out.

- HEURION CONSULTING INFORMATION RELEASE

So in the basic sense, whenever there is a need to connect Parent and Child tables with belongs_to and has_many relationship, developers generally use the following known table relationship i.e. Database Information.

1. Create the Parents table with ID.

2. Create the Children table with ID.

3. Add a Field by name parent_id in children table Model Information.

In Parent model, add an association to the child model.

class Parent < ActiveRecord::Base
has_many :children
end

In Child model, add an association to parent model.

class Child < ActiveRecord::Base
belongs_to :parent
end

This is a basic idea of using a belongs_to and has_many relationships and solves most of the problems used in rails programming.

However, when there exists that multiple connectivity is required in a particular Parent-Child relationship, then this concept does not work. Considering the above example, the requirement says that for any child record in the children table, there can exist only one parent table. Sometimes there exists a requirement of more than one entry e.g. Mother and Father is a parent for a child. So when there is a requirement to have a child record created with 2 foreign keys of Parents table i.e. one for father_id and another for mother_id, the above concept does not work.

In this kind of relationship, the solution is to modify the above requirement as Database Information.

1. Create the Parents table with ID.

2. Create the Children table with ID.

3. Add 2 fields by name father_id and mother_id in the children table.

Model Information in Parent model adds an association to the child model.

class Parent < ActiveRecord::Base
has_many :children
end

Model information in Child model adds an association to parent model.

class Child < ActiveRecord::Base

belongs_to :father, :class_name => “Parent”, :foreign_key => “father_id”
belongs_to :mother, :class_name => “Parent”, :foreign_key => “mother_id”

end

Another typical example to explain this need is in a shopping cart where you would have an order attached to 2 different addresses such as shipping address and billing address, where both are of type address. In the example, the subject of interest is using the belongs_to methodology. Let us investigate what the above sentence mean.

belongs_to :father, :class_name=>“Parent”, :foreign_key=>“father_id”

When we say belongs_to :father, we mean that you can use the keyword father to get information about the father object i.e.

@child = params[:selectedchild]
@father = @child.father
@father…. #Get father details….

Since there does not exist any table as father, we explicitly instruct the Model to consider this Father object to be an entry in the Parent object (table) and could be accessed by the foreign_key father_id of the children table.

Hope this post explains how to solve multiple elements of a parent within a child record.

– Heurion Consulting Information Release

• :conditions (for where clause)
• rder (determines the order)
• :group (grouping data)
• :limit(specify maximum number of rows to be retrieved)
• ffset(number of records to be omitted)
• :joins(join multiple tables)
• :include(for associations with left outer join)
• :select(to specify the attributes of the output data)
• :readonly(to execute as reader)

In this post, we shall not look into more details of each of this segment, possibly we can write another post to provide information on these. So most of the queries that are used by Rails developers are any of the above ones. However it becomes an issue to resolve. I shall explain in this post 3 methods which makes developers’ life easy. These finders are:

1. Query finder Method (Generalized Finder) : Query finder is a methodology where the user finds information from the database by use of SQL queries. The developer uses standard SQL Queries in multiple form and executes them using the find_by_sql method.
2. Dynamic finder Method (Specialized Finder) : This method uses the method_missing method of the ActiveRecord::Base class to identify and create finder methods which can be declared and used dynamically. However these have to follow some rules.They can be applied only in conjunction with table fields. The four methods used are find_by_xxx, find_all_by_xxx, find_or_create_by_xxx and find_or_initialize_by_xxx methods. Dynamic finders also use the _and_ keyword to use multiple table fields in the single request.
3. Custom finder Method (Customized Finder): This method uses writing custom find* methods which could be either un-conventional method (not as used in above methods) or override the methods declared by the ActiveRecord::Base. Custom finders are declared in the Model objects and are generally tagged by self keyword.

METHOD #1: Query Finders Method (Generalized Find)

Many a times the developers are comfortable to use standard SQL queries to write their applications database requests rather than using any of the above find methods or parameters and they get lost identifying these parameters. Also for complex queries it becomes difficult to use.

However ActiveRecord::Base again comes to the rescue and gives one another method find_by_sql . Using this method the developers can write SQL queries and execute them. The advantage of this system would also be that it could be used for executing stored procedures also. This is advantageous because MySQL 5.0 comes in with Stored Procedures.

The following are few examples of using find_by_sql methods

Retrieving complete information of selected records:

Developers can just key in the sql query and get the information. Example:

@loggedinusers = User.find_by_sql(“select * from users where loggedin=true;”)

The @loggedinusers element shall contain all the logged in users information.

However if there are inputs required which are unknown then generic find by sql could be written as similar to :conditions of Find method. An example could be as follows:

@loggedinusers =User.find_by_sql(["select * from users where loggedin=? and isActive=?",@isloggedin,@isactive]

Retrieving partial information as required:

In the above example, we identified that the inputs could be varied and outputs has to be the complete database record. When these operations are done, the advantage is that the objects can be directly mapped to a particular database record. However in this world there are requirements of all types. There are requirements where only particular information has to be populated for these types of inputs we could use.

@loggedinusers = User.find_by_sql(["SELECT username, lastloggedindate, isActive FROM users"])

The @loggedinusers contains only the information about the username, lastloggedindate and isActive. The following code snippet can be used to get the information:

loggedinuser = @loggedinusers [0]
puts loggedinuser.username
puts loggedinuser.lastloggedindate
puts loggedinuser.isActive

METHOD #2: Dynamic Finders Method (Specialized Find )

Dynamic finders are a method of finding information based on particular database field of a table. If find_by_sql method provides a generalized method to query information from the database, by using dynamic finders, you can construct methods to find records based on specific requirements which are input as parameters.

There are 4 types of dynamic finders which can be used:

1. find_by_XXX methods: Finds the first row for a given database field name(s).
2. find_all_by_XXX methods: Finds all the rows that satisfies a given database field name(s).
3. find_or_initialize_by_XXX: Finds a row with a given parameter(s) and if not available, creates a new row and returns back to the user the empty object to be filled.
4. find_or_create_by_XXX methods: Finds a row with particular parameters and if not available, then will be created in the database with the input parameters and then returned.

find_by_XXX methods:

This method is used to find any record by a given input parameter. This makes developers’ life easier to find records by any database field. One example would be is to find the record of the person whose username is ‘heurionconsulting’.

@user= User.find_by_username(“heurionconsulting”)

The example writes to :
@user = User.find_by_sql(["SELECT Top(1) * FROM users WHERE username=?","heurionconsulting"])

The advantage of this is the find_by_xxx can also be added in conjunction with _and_ option if we have to add multiple database fields to create a query. We could modify our earlier example to find the first user who has logged in last and is a purchaser.

@firstloggedinuser= User.find_by_loggedindate_and_ispurchaser( “05/08/2007″ , “true” )

The above example explains to return the first user information who has loggedindate and is a purchaser. This is equivalent to
@firstloggedinuser = User.find_by_sql(“SELECT Top(1) * FROM users WHERE loggedindate=’05/08/2007′ AND ispurchaser=’true’; “)

Use of keyword _and_ helps to identify all the database fields which is required to achieve the output.
This method is used only to get the first record of the result only.

find_all_by_XXX methods:

This method is similar to the find_by_XXX method, but this is used when you want all the records that satisfy the criteria. The _and_ criteria could be used for this object as well.
An example of find_all_by_XXX method could be as follows:

@loggedinusers= User.find_all_by_loggedindate_and_ispurchaser( “05/08/2007″ , “true”)

This example results in:

@loggedinusers = User.find_by_sql(“SELECT * FROM users WHERE loggedindate= ’05/08/2007′ AND ispurchaser=’true’; “)

find_or_initialize_by_XXX methods:

@product= Product.find_or_initialize_by_product_name(“MUG”)

if@product.product_name.nil?
redirect_to :action=>‘viewproduct’, :locals=>{:product => @product}
else
redirect_to :action=>‘newproduct’,:locals=>{:product => @product}
end
In the above example, the method shall first find if “MUG” is available in the database. If the product is not available, then the user could create a new product with a new product id and the product name shall be “MUG”. So in the newproduct page the user sets only those information which is missing and saves the information to the database.

find_or_create_by_XXX methods:

This method is a complement of the find_by_intialize_by_XXX where in the initialize case, the user just initializes the object with the input information and gets the object. Whereas in case of find_or_create_by_XXX method, the user can provide complete information required to save an object. Modifying the above example we could re-write it as:

@product = Product.find_or_create_by_product_name(“MUG”,:create_args => {:product_name => ‘Mug’, :description=>“New Product”, :availability=>true})

This method uses a :create_args parameter which has to be filled if the object is not found. So if there is no product by name mug, then create a product and set its information as in the :create_args section and return the object.

P.S: All these 4 dynamic finder methods are actually calculated in the method_missing method declared in the ActiveRecord::Base.

METHOD #3: Custom Finders Method (Customized Find)

In the earlier 2 types we have queried the database by: a) Providing the complete sql syntax i.e. find_by_sql method and b) By modifying the find method to read the required syntax i.e. find_by/all_ or find_or_initialize/create_by methods. Both of these methods are good and have advantages on their own. But there are many other scenarios where any of these methods cannot be used.

One classic example would be where you would like to evaluate a scenario before you call the Active record’s find method. For such scenarios the best approach is to use custom finders.

Custom finders are nothing but writing find methods within the Model and call the ActiveRecord::Base::Find* methods from these methods. Custom finders generally are self methods declared in the Model object.

#Product.rb — Model file

def self.find_product_by_status(status)
if status != utofshelf
Product.find_by_sql ["SELECT * FROM product WHERE status=?",status]
else
Product.find_by_sql ["SELECT * FROM product WHERE status= 'outofshelf' AND availability=false"]
end
end

The example above identifies a custom finder where it checks if the status is not out of shelf, then get all the products based on the status and if it is out of shelf, then check the status and also is not available. Also if you see the name of the find method it is an un-conventional name find _product_by_status instead of find_by_status.

Developers can utilize custom finder to name methods by thier own way or even custom finders can also be used to over write the method names which exists in the ActiveRecord::Base class. An example can be found as follows:

#Product.rb — Model file

def self.find_by_status(status)
if status != utofshelf
Product.find_by_sql ["SELECT * FROM product WHERE status=? AND availability=false"]
else
super
end
end

In this example, you see that the custom finder has the same name as a find_by_status method which is a standard ActiveRecord::Base method and has been overwritten by the find method in the Model file. In the example, we have also dealt in re-directing the custom finder method back to its parent method by using the super keyword.

To Summarize

In this post we have explained various types of find methods.

1. We have explained in brief about Find method and its parameters. However going in depth of this method is out of the scope of this article.
2. We have dealt with how to use find_by_sql method to query complete and partial record information (with and with out multiple inputs).
3. We have come across how to use dynamic finders by just the names of the database fields with _and_ combination to find single, all, find & initialize and find & create methods by using find_by/all_ and find_or_create/initialize_by methods.
4. We have also explained how to use custom finders which can be used either as a wrapper on general find methods or override the ActiveRecord::Base‘s find methods.

We hope these information is useful for the reader and are open to any comments.

– Heurion Consulting Information Release

The Problem

In-Place Editing is a wonderful AJAX based tool that helps users to provide a text field to update and render information that suits the Web2.0 building. Users can use In-Place Editor to either directly connect to a database record for query and updating or can make use of set_XXX_YYY methods to update yourself.

The main issue of In-Place Editor is that it has direct links to update the database record or possibly you can validate information. However there is no way directly if you have multiple elements of the page to be updated according to the information provided in the In-Place Editor.

The Solution

The Solution to update multiple elements after the In-Place editor updates itself can be achieved using RJS (Ruby Java Script). You can first use the In-Place Editor to take inputs from the user and then once you submit information to the database, you can call an RJS to update the In-Place editor and any other elements in the page.

The Case Study

In this case study we shall assume that the user knows what RJS and In-Place editing is all about, but doesn’t know how to link both.

The Case Study is based on an issue which was identified by us few days ago, where we were using In-Place Editor to take inputs about the width and height of an image and store it in the database. However we also had to update our preview image to show this width and height.

The Case study uses a table by name images which holds information such as id, name, width and height and we assume these images are stored with-in public/images/sampleimages folder with the id as image name. (In the example you shall see us referring to this link.)

The Method

Lets start this method from the base and then come towards the UI.

First is the Database:
We create a Table by name images with id, name, width and height information.

Once the database is ready, we start the coding part. As it is known, we directly use the table information, not doing any validation part . So lets keep it simple and do anything at the model end.

Coming to the controller, we have 2 parts to do:

1. Create a method which shall launch the rhtml. Lets do all our work to pass to the viewimage.rhtml.
2. Update the image information when user clicks on Ok in the In-Place Editor.

So our Controller should look as follows:

class CategoryadminController < ApplicationController

def viewimage
@image = Image.find(params[:id])
end

end

All we do here is to get the selected image from the database and put it into the @image variable. Once our method is ready we are set to write the viewimage.rhtml. In the viewimage.rhtml file, we have the following elements:

1. We have an area where we show the name. This can be a simple in_place_editor_field which you can get updated directly with the database (out of our scope).
2. We have an area where user can see the preview image with the width and height of the image.
3. We have an area where we show width and height of the image. This uses in_place_editor and update on these fields should affect the preview image’s width and height

The code for all these three should look as follows:

<div id=“image_info”>

<span id=“name” ><%= @image.name %></span> <br />

<span id=“width” ><%= @image.width %></span><br />
<%= in_place_editor “width”, {:url =>url_for :action=>“set_image_width” , :id=>@image.id) , :script=>true } %> <span id=“height” ><%= @image.height %></span><br />
<%= in_place_editor “height”, {:url =>url_for (:action => “set_image_height” , :id=>@image.id) , :script=>true} %>

</div>

<div id=“image_preview”>
<%= image_tag “/images/sampleimages/#{@image.id}.jpg”, { :width=>@image.width, height => @image.height } %>
</div>

If you see the in place editor you will see that on click of the ok button you have to raise set_image_width method in the controller and also you see :script=>true which means that once the method is called in the controller its next step is to call the RJS.

So now let us update our controller code with these set_XXX_YYY methods. Our controller should now look like:

def set_image_width
image = Image.find(params[:id])
image.width = params[:value]
image.save
@image = image
end

def set_image_height
image = Image.find(params[:id])
image.height = params[:value]
image.save
@image = image
end

In the above code what we see is first get the image object, get the value of the in_place_editor and save the information to the database. Once this work is completed, our last piece is to update the RJS. The setting :script=>true in the viewimage.rhtml and @image = image in the controller should help us to run the RJS file to replace the information.

First of all you have to create an RJS file which is of the same name as the controller method which is being used. In this case it should be set_image_width.rjs and set_image_height.rjs. Once you create these files, all you have to do is query the image object and reload the div so that new information is reflected in your object.
#set_image_width.rjs
page[:width].replace_html( @image.width)
page[:image_preview].replace_html(image_tag( “/images/sampleimages/#{@image.id}.jpg”, {:width=>@image.width, :height=>@image.height}))

What we do in the RJS file is:

1. Replace the In-place Editor span Id with the new modified change — In-place editor by default doesn’t do it.
2. Replace the Preview-image section with the latest width and height information. Sometimes you could just call reload method on the div, but we don’t see it working consistently.

The Summary

Before we end this session, let us summarize the following:

1. We used In-Place Editor to provide text editing.
2. We used set_image_xxx methods to validate and save image objects.
3. We used :script => true to make the in_place_editor to call the RJS file.
4. We created an set_image_xxx.rjs file where we first replaced the width/height span information with latest image width/height and also set the Preview image’s width and height parameter to be as what is available in the corresponding image object.

– Heurion Consulting Information Release

Disclaimer: This post is made only to point out few areas of technology information which might be interested for different kinds of people. And those who would want to benefit from this can do so. This Post is our organization’s evaluation of the seminar and holds no other information or criteria in hosting this. Heurion Consulting has NOT been paid by any person to write this post.

Master Class Series Seminars are a new class of technology seminars that Thought Works have started in Bangalore India, This is their second year. Unfortunately I didn’t attend the first one.

The Programme was divided into 3 technology discussions each of them were in different segments of software life cycle. I shall not concentrate on the initial speech or the last vote of thanks because my concentration is on the technology discussion and how it will help us. Also as we know Thought works is known for their agile development practices, they are releasing new software for project management. The technologies discussed were as follows

1. Database Refactoring
2. Evolutionary testing
3. Domain Specific Languages

Database Refactoring was presented by Mr. Pramod Sadalage and identifies use of evolutionary development methodologies such as Extreme Programming, Feature Driven Development to make it clear that developers and DBA need to work together in the same manner to be productive as a team. He presented information and material from his book on “Refactoring Databases: Evolutionary Database Design” on how to go about doing evolutionary database development and talked about techniques of database Refactoring, evolutionary data modeling, database testing, configuration Management of database artifacts and developer sandboxes. In his presentation, what we understood was more similar to how the Ruby on Rails technology looks at the Database to be part of the developer frame work. However we see that in his presentation he concentrated that even other technologies could adopt these principles. In his presentation we could list the following points of action.

1. He explains the technique of Developer and DBA to be working together making a pair (This exposes to a concept called as Pair Programming and guys trust me, it works, I have done it some time back). He identified that DBAs should also be part of the cycle where the database elements are being decided. He pointed out that DBA == ROLE != Person
2. He identified the need for the Database Scripts to be in the source control (similar to our DB/migrate scripts in the code. If some one is not using the Latest Rails framework, they wouldn’t know what is db/migrate scripts)
3. He identifies by use of scripts it becomes easy for any person joining an organization to come to speed by automating scripts to create databases by use of ants, subversions, cruise control, etc
4. He identified how to break all the DB migrations into delta scripts for easy management of the scripts. He demonstrated by naming the scripts with XXX_NAMEOFSCRIPT.sql where XXX refers to the version of the database and these scripts would contain 2 sections one for a Go and other for Undo action (very similar to our Migration script i.e. naming with 002_CREATE_TABLE and having a self.up and self.down sections in the migration files)
5. He demonstrated these functions with examples and used svn and cruisecontrol for version controlling. We were able to appreciate cruise control’s usage in build creation. We understand that cruise control is used for creating versions of build and whenever we do a checkin to the svn, cruise control does a build and checks if the code is up to date. I think we need to try this out and see if this brings us advantage to us. For Ruby on rails, there is cruisecontrol.rb

Pramod also has a website www.databaserefactoring.com where he has identified many areas and methods of Refactoring.

For the question that I asked him that RoR already does all these things, so what is new for us? I understand that what we do is migrating data from ruby code and not sql scripts and for thousands of database entries; running migration from the code is costly? I don’t know how far it is true, but since it comes from the horse’s mouth, let me accept it until I find some one telling me that this is not true.

Evolutionary Testing was presented by Mr. Vivek Prahlad who is also one of the designers of the Frankenstein tool. In his presentation he pointed out the usage of their testing tool called Selenium which can do functional testing and UI testing. Selenium has the following features.

1. It is an Open source tool, so we can write extensions to the same to support our testing needs. They expose some APIs
2. It has cross browser support. Selenium, comes with plug-ins, which are added to each of the browsers, so with firefox, they have a plugin at tools à selenium and this plugin can be used to record information of testing and do the testing.
3. It can test minimal Ajax implementation (but not complete Web 2.0 aspects. Well what features they support and they don’t support, I feel there are many, however what I felt was that this does not support is the Scriptaculous effects. If I have some time, then I shall find out more information on the same).
4. It supports many languages including Ruby.
5. Mainly for Functional Testing, but also supports UI testing.

Selenium has some features like Recording which helps to record actions on tests and run them on different browsers, These recordings can also be converted to code and write test scripts. The advantage with Selenium is that we can write code in Ruby on Rails. Selenium also supports DRY, use of methods, parameterization and also is object oriented. During the presentations he took through 3 testing patterns and explained how Selenium can support these operations. The patterns were

1. Screen flow pattern
2. Data Template Pattern
3. Work flow pattern

P.S: When I spoke to Sidu one of the thought worker, he said Frankenstein tool also has Ruby Drivers. I think its worth checking it out.

Domain Specific Language section was presented by Mr. Srihari who identified a need of writing specific interpreters / rule engines for particular domains. He picked this from one of their Ruby on Rails projects where they wrote an interpreter and a parser which converts user’s English language to be interpreted by use of a parser and Rails project. This project used RACC (Ruby’s port of YACC) and for lexical Scanning they used Ruby’s string scan. However this presentation didn’t give us much information of the exact need and how their approach was. But it was informative to get an understanding that if we have to provide a language for the users to key in rules, then the best solution approach would be to use a Domain Specific Language which is understood by the users.

P.S: I didn’t appreciate this presentation until I found that there is a book written for this the link is as follows http://www.pragmaticprogrammer.com/titles/tpantlr/index.html . Now I appreciate what he was trying to tell us.

P.P.S: Sidu says “You may also want to mention that everyone’s favorite Rails Migrations are a classic example of a DSL.” Thanks for the information Sidu.

Other to these presentations, I was in a discussion with one of the Thoughtworkers regarding their Project Management Product called MINGLE. This is a project management tool for agile practices and helps in handling iterations and planning stories. This tool has the following features.

1. Manage Agile projects
2. Configurable to any industry
3. Easy management
4. Good UI

The beauty of this tool is that it is developed using Ruby on Rails and has lots of AJAX stuff in it. I got Mr. Kedar (a Thought worker) to give me a demo and it looked good. I understand the BETA release is some time in next 2 months and we can download and test. Also for a < 5 member team, it’s free. You can find more details of Mingle @ http://studios.thoughtworks.com/mingle-project-intelligence

Hope these are informative. We are planning to test CruiseControl.rb, Frankestine and Selenium and try and integrate with our systems. Once done, we shall put a post on this as well.

So till then….do the Ruby on the chuk book chuk book…..(The Rails….)

- Heurion Consulting Information Release