BioNuc talks ....

[bionuc-blog]

Concurrency & Atomicity

If you wanna produce correct working code, you have to understand well that we are living in a world where things are running in parallel. So your server can get more than 1 request at a time

This can lead to major issues on the backend if not well handled

This code will work fine in sequential environment

user = User.first user.money -= 50.dollar user.save!

Here you are reading the amount of money the user has then deducing 50 dollars from his account (maybe because he purchased something) then saving the user again

If this code ran twice at the same time, you can face this race condition

Request 1 loaded user object with remaining money

Request 2 loaded user object with same remaining money

Request 1 deduced money and save user

Request 2 deducted money (old value although it has changed already) and save user

The end result is that the user was able to do two purchases each for 50 dollar but actually just 50 dollar was deduced rather than 100 dollar

The problem is originated because your code is doing two transactions 1 to read the amount and another to deduce but actually both operations should be part of the same transaction. If you made it part of the same transaction, request two will wait for request 1 to deduce money as it will be locked by your DB engine

You must consider this concept of “Atomicity” in all your work and operations

Note that validations when you run save! are done as part of the transaction which is a good thing

[bionuc-blog]

How to Create a Vagrant Base Box from an Existing One

This is a good way to create a vagrant box from existing base box after adding needed packages you need

[bionuc-blog]

Window.postMessage()

This is a way to exchange message between parent and nested iframe

Can be used to support cross-domain communication without violating user security

[bionuc-blog]

Threading & DB Connections

Threads inside any process can use (pool -1) database connections because 1 connection is used by process main thread

Always release thread active connections with DB at the end to save time and ensure thread is not holding any connections

[bionuc-blog]

Use “after_commit” and “after_rollback” instead or “after_save” if you want to do some operations that are not part of DB transaction This is useful because doing a lot of work inside a transaction will lead to slowdown on DB queries and maybe can lead to deadlock because the DB will lock all rows until operation is done

[bionuc-blog]

mobile_fu & difference between mobile view and mobile device

If you dealt or about to consider using “mobile_fu” gem to support multiple views for the same controller action then you have to take care of this note I will mention here

Normally mobile_fu create a new format as “mobile” to differentiate mobile view from desktop view so that a url as “/topics” will have two versions “/topics” and “/topics.mobile”. The first will show the desktop version and the second will show the mobile view. This is regardless of the User-Agent which state if the source of the request is coming from desktop or mobile

I am assuming here that tablet is using the same view as desktop but you can have additional format “tablet” if you wanna have a separate view for tablets

If you called /topics directly then normally you will get either desktop view or mobile view and this will be based on your device. mobile_fu has a method “is_mobile_device?” that can be used to know if source of the call is mobile or not

So what about “mobile view” which is something different provided by mobile_fu named “is_mobile_view?” ? This is added by mobile_fu because in many web services, you might want to handle these 4 cases

Mobile Device + Mobile View

Desktop Device + Desktop View

Mobile Device + Desktop View (if you allow mobile users to see full version of the site in case you support limited set of features on mobile and user switch to desktop to use website full functionality)

Desktop Device + Mobile View (in case you wanna use the mobile view instead of the desktop view for whatever reason you have in mind. This is not a common thing websites support but can happen if someone is following a mobile url shared with him)

To have these 4 cases supported, we have to rely on two pieces of info. The first is “User Agent” which is used to know if device is mobile or not. The other piece of info can come from a cookie to store user preference. Initially a user coming from mobile will have the website served in mobile view but when user switches to desktop view, we store this preference to use move forward

When it comes to AJAX, you have to send the format in the url you are requesting so you have to call either /topics or /topics.mobile so that the server responds with the appropriate response based on whether this device is mobile or not and also based request is coming from mobile view or not. Without format, you won’t be able to do so as “in_mobile_view?” will always return false as mobile_fu logic is bypassed in case of XHR requests

[bionuc-blog]

request.xhr? in Rails 3

In Rails 3, you shouldn’t rely on request.xhr? to know if request is done via AJAX or not because this is not a method that returns true or false but a predicate function that returns the index of the first match so this can return 0 which will lead to false in any check

To overcome this, always use !!request.xhr? to do the check

[bionuc-blog]

Ajax Request & Format

For a url like “/topics”, you can decide two things in your request. The first factor is the format and the second factor is how data will be loaded

Formats available are ones like HTML and JSON and xml and you state it with urls like that “/topics” for HTML and “/topics.json” for JSON response

Data can be loaded by normal requests or via AJAX

The format shouldn't state the type of the request whether normal or AJAXified one. Thats why it is not recommended to create a new format “js” to differ normal requests from Ajaxified requests. So Don’t make a request like “/topics.js”

You can know if the data is loaded by normal request or AJAX in another way which is through headers. In Rails, there is a method named “xhr?” on request object that can state if request was made via AJAX or not. Always rely on that instead of adding new format

[bionuc-blog]

Track your service Uptime

For any web solution, it is always recommended to track the uptime of your service to track any incident when system is down To do so, we do an inspection technique by visiting some endpoints at the web service regularly (every 1 minute for example) to make sure server is up and serving us normally When server is down, this can mean either it is down completely or it is not in a stable state and requests reaching to server are too much that the server queue them for long time until their time come to be served. Normally any client will drop connection after x seconds and will consider your server down if it was that late This variable x helps you not only to track that server is up but also to track if server is reliable or not. A reliable service shouldn’t have long response time which is the aggregation of service time and queue time Normally, these uptime tracking services will ask you for some endpoints to call every now and then. I prefer giving them urls that take almost 0 service time so that this way response time = queue time and this is the metric I am interested in measuring more but in most of cases, queue time is the cause of increased response time assuming that you have optimized your service time well Use 1 endpoint or more based on your case. In some systems, you might cluster requests between several servers so you need to track each system on its own. In some systems, some requests are served from web server using page caching and some are served from app server so in this case you need to track both systems uptime since they are de-coupled from each other

[bionuc-blog]

Dealing with Source Control

Source Control systems are very common but to get the best out of them you have to follow some guidelines to make things better

Each commit must have a clear reason stated

Divide your changed files into more than 1 commit. Don’t add all to 1 commit and push. Each commit should represent a completed added value such as “Fixing bug X” or “Introducing Feature Y”. Many people tend to combine things in 1 commit. The drawback of this is that if you wanted to rollback the fix, you will need to rollback many other stuff because all files are added in one logical grouping which is the “Commit”

To patch your production environment, do the fix on production git branch and then commit the fix on its own without including any additional un-related files then cherry-pick your commit to development branch if possible. In some cases, you can’t do so because your new codebase is revamping the way things are done so you can’t merge a fix related to an older codebase version

It is better to link commits to tickets you have in your project management tool. One way to do so is to add something like #23456 (which is the id of the ticket) to the commit message. This will allow you also to automatically link project management with Github which is a feature available in several project management tools now and helps you when enabled to add a comment on the ticket with the url of the added commit. This will make your ticket complete as it has the story and comments and commits made

If you are making a major change then it is preferred to create a local branch and do all the work and test things and maybe push this local branch to remote git server to test on a staging environment then once all good, you merge things back to main development branch

[bionuc-blog]

[bionuc-blog]

Get vs Post/Put Requests

It is very important to decide the http verb you will use when adding any route

Normally GET http verb should be used only for read operations or operations that don’t alter system state

Post/Put http verbs should be used for operations that alter system state. I won’t explain here when to use Post and when to use Put and when to use Patch

Why ?

This is the right way to do things

Get requests can be easily made so this way your urls can be called easily from any browser. This can ease things on newbie hackers who wanna play with your endpoints

In case you added this url directly in dom, it will be easily crawled by bots to be indexed but if this method is only available if POST/Put is used then these urls will be dropped as server will respond with 404 status code

[bionuc-blog]

This is one weird new thing for me at least It might look silly for you that we should use PATCH for partial and full updates and PUT only for full updates but this is what should be done if you care about having things semantically right This small article worth reading to get an understanding about differences between both of these two HTTP verbs