Here is the problem, you need to merge some works from "stable" branch in "repo1" to your current "master" branch. Below are the steps you do. First of all, add a remote repository

git remote add foo git@example.com:foo/repo1.git

then download objects and refs from that newly added remote repository

git fetch foo

now checkout the branch which will you merge, in this case "stable"

git checkout --track -b stable foo/stable

then you move back to your current directory

git checkout master

from this point, you can merge "stable" branch to your current "master" branch by using

git merge stable

if the changes don't conflict, you're done. Alternatively, you can pick out individual commits from "repo1/stable" to your current branch by using

git cherry-pick refnumber

Got better solutions? Please share it on the comments.

Thanks to the guys that build BrowserCMS, our lives has just gotten easier! No longer we have to stick with Radiant, BrowserCMS is, we think, easier and more robust. This post is a simple getting started guide, that will help you to:

1. Install the BrowserCMS
2. Create a new page
3. Add text content to the newly created page
4. Publish your page

Continue reading...

We have done multi-language feature for several Rails applications in the past, using gettext, gibberish, gibberish_db, etc. In this blog post I want to share the latest multi-language feature we built for our Netherland client recently, using Globalize2 plugin and Rails built-in I18n. We used I18n for all our static contents, it's a piece of cake. And all the client needs to do is to update that ymls files. For dynamic contents, we use Globalize2. Here comes the fun part. Because you are most likely be working on an existing application, the bulk of the work is not making a nice back-end for multi-language objects, but it's making sure the Rails application works correctly after we implement multi-language. It's especially true when the application doesn't have a complete test suite :) Some things worth noting:

1. All occurrences of find_by_name will no longer work correctly. So grep that and modify accordingly
2. Basically all queries that use 'name' field, either on the select clause or condition clause, will also no longer work correctly
3. All routes that need locale path should also be added /locale/ to it
4. Javascript methods within a .js file that calls a Rails action and needs 'locale'. Simply make a global Javascript variable for the locale and use that when necessary within the .js file
5. Javascript method that uses hard-coded words. Eg. "this.value = 'Beware'". Either we refactor it completely since it's most likely we can do it another cleaner way, or we have to pull out that Javascript method from .js file to rhtml

If you need a partner in developing your next Multi-language Rails application, we may be able to offer a good help! Contact us at info[at]kiranatama[dot]com

About a month ago one of our development teams is fortunate enough to have the chance implementing ServiceMerchant plugin It is a plugin that makes use of ActiveMerchant, but designed specifically for recurring billing / subscription payment requirement. As with all other gems, the best way to understand a gem, besides asking shifu Google, is to dig into the gem code itself and find sample apps, example usage, test units, etc It's pretty straightforward, and yet I feel like wanting to share some interesting things:

1. If your PayPal timezone is different from your server's timezone, you have to take note. Otherwise PayPal might refuse user payment because the start subscription time is in the past! Assuming you are saving times in UTC in your database, the following code would work well as the start subscription date passed to PayPal: TZInfo::Timezone.get(PAYPAL_TIMEZONE).utc_to_local(subscription.starts_on)
2. You want to keep a history of user activities (valid payments, invalid payments, cancellation, etc). In this case you'll have to set a notification URL in your PayPal setting. Make sure the URL is accessible by Paypal, and check the example in ActiveMerchant:

   /lib/active_merchant/billing/integrations/paypal/notification.rb

The necessary tweak is that we have to handle the case where a subscribing customer's credit card on file has expired or becomes invalid - in which case we have to terminate the customer's subscription on our database. Btw if you need to develop a recurring billing paypal feature on your Rails app, we may be a good partner. Contact us info[at]kiranatama[dot]com

Probably you already know about n+1 queries problem, read this post if you want to learn how to detect those kind of queries.

Continue reading...