Vinsol Allures GoodFirms Recognition for Exclusive Mobile App Development Services

Vinsol listed as top app development company in San Francisco

Vinsol is recognized as one of the popular mobile app development organizations by GoodFirms.The company has its offices in San Francisco (United States) and Delhi (India). Vinsol has strongly evolved, making remarkable progress in mobile app development and has delivered more than 150 applications including some renowned names in the industry.

Read more


Multiple-Databases In Single Rails Application

This is a simple post to list some of the challenges faced during multiple database setup in a single rails application. The content in the post is available over the internet, we have consolidated it here to bring it at one place.

While integrating multiple third party services we felt the need to store each and every pair of request-response shared between our application and others. We decided to use database tables to store this information instead of files or other options so to have an easy disintegration of data. This helped us in filtering for some particular handshakes based on certain scenarios. Also we could pick requests that failed to respond or if any request claimed to be sent to us but never did.

We thought it would be better to place this in a separate database to avoid clouding our main database. Plus we could also avoid picking up this content while backing up our already big database, as this was not that “critical”.

So we set our sails in this direction and Rails made it very easy by letting us set up different database connections for such classes/models.
Read more


Migrating from Protected Attributes to Strong Parameters

In Rails3, we use attr_accessible or attr_protected(Protected Attributes) to white-list attributes of a model for mass assignment.
In Rails4, Protected Attributes was moved out as a Gem and similar feature was implemented at the controller level, which is now known as Strong Parameters.

We were migrating one of our project from Rails3 to Rails4 and decided to use Rails' Strong Parameter instead of using the Protected Attributes Gem. While migrating from Protected Attributes to Strong Parameters we found ourself in a situation where we were repeating the same code. To elaborate, in Rails3 when we used Protected Attribute, all our white-listed attributes were at one place i.e. in the model itself. But when we used Strong Parameters, all these attributes of model came into the controllers, so if we had more than one controller dealing with same model, we were repeating the code for white-listing attributes in each controller.Read more


EmberJS: Snagged by belongsTo association

Writing Javascript code using MVC framework and rendering templates at client side is the new fancy way of writing web applications. As they say, when Rails is the backend, Emberjs at frontend is a good fit.

The beauty of the architecture along with our excitement has impelled us to dive into this framework. It started with revamping of an eCommerce site by building its version-2 using Emberjs as frontend framework and Rails as an api server. Initially, everything was working fine and we were enjoying our Emberjs learning and implementation, but in the following scenario belongsTo association has become a stumbling block for us.

Before we talk about the obstacle, let us share what tools we are using and how we are trying to integrate Emberjs and Rails.

Read more


User Phone Verification - A way to prevent fraud in e-commerce

Recently in one of our e-commerce projects we implemented phone verification for users to have authentic accounts at our website. The requirement was to have one account per user to avoid misuse of offers provided by our service on scenarios like signup, high-value purchase, referring a new user to shop at our site plus other special offers.

So we decided to verify users using phone number verification that seemed more reliable than email verification since having multiple phone numbers is not as easy and rare as compared to having multiple email accounts. We then chalked out a simple approach that came out ineffective and needed a renovation.

Initial Approach:

Save a phone number corresponding to a user that he can verify later by the one time verification code sent to his phone. We then ensure that the phone number is not verified against other account to have an account per user on verification request. Things seemed to go well but didn’t serve the purpose as expected.

During our revisit to the approach we found out that a user still could create multiple accounts. If you missed it too, here is how it goes:

Suppose, a user say, Haitham signs up with account A1 and verifies his account with number, N1. Now once he needs another account to avail more offers he can simply edit his number to say, N2 and not verify it. Then he can create another account say A2, and verify this new account using N1. As in the application’s use case of 'referring a new user to shop at our site', he could add himself as a referrer using account A1 for A2. Hence, the whole idea of fraud detection and prevention was deceived.

Magic Trick:

Don’t associate a number with a user until the user verifies the number.

The simple change above solved our issue to all possible levels.
Read more